Pregunta sobre rutas anidadas en una API RESTful de NestJS.
Estoy diseñando una API RESTful en NestJS para un proyecto y estoy teniendo dificultades para manejar las rutas anidadas. Aquí tienes una descripción general:
- La autenticación se realiza en el frontend mediante Firebase. El token se envía a la API para ser verificado, lo cual ocurre en un middleware. Si la verificación es exitosa, se adjunta el ID del usuario de Firebase a la solicitud y se reenvía.
- Cada usuario puede crear múltiples perfiles de mascotas, que se encuentran bajo el endpoint “/profiles”. Todas las operaciones CRUD están admitidas.
- Cada perfil de mascota puede tener varios recursos relacionados, como notas.
- Todos los tipos de recursos están separados por módulos de Nest, que contienen la entidad, el servicio, etc.
Aquí llegamos a la parte que no puedo comprender. Tendría sentido anidar los recursos de la siguiente manera: “/profiles/:profileId/notes”.
Anidando aún más, por ejemplo, una nota específica sería: “/profiles/:profileId/notes/:noteId” y así sucesivamente. Las operaciones CRUD también se manejarían en ese lugar.
Lo que me molesta es que, al seguir este enfoque, terminaría teniendo un único controlador para toda la aplicación, es decir, el controlador de Perfiles.
Otro enfoque que consideré fue tener los métodos “GET ALL” y “POST” bajo el controlador de Perfiles y “GET”, “PUT” y “DELETE” bajo un controlador específico del módulo, por ejemplo, “/notes/:noteId”. Pero en ese caso, no sé cómo proteger esos subrecursos, ya que no tendría disponible el profileId de esa forma, y no sabría si el solicitante es el propietario del perfil para autorizar esas operaciones.
¿Cómo manejarías este problema? Gracias por las respuestas.
davy.ai
Hay diferentes enfoques para manejar rutas anidadas en una API RESTful de NestJS. Una posible solución es utilizar subrecursos, como se sugiere en la pregunta, donde cada subrecurso tiene su propio endpoint REST. Esto permite una estructura de URL clara y concisa, pero puede resultar en un único controlador que maneje todas las solicitudes.
Otra opción es utilizar una combinación de enrutamiento basado en recursos y enrutamiento basado en controladores. Por ejemplo, la API podría utilizar
/perfiles/:profileId/notaspara operaciones CRUD en notas relacionadas con un perfil específico, y/notas/:noteIdpara operaciones CRUD en notas individuales. Este enfoque permite un mejor control sobre la autorización y autenticación, ya que cada controlador puede manejar sus propias políticas de seguridad.Para asegurarse de que el solicitante sea el propietario del perfil, la API podría utilizar middleware para verificar el ID de usuario adjunto a la solicitud y compararlo con el propietario del perfil solicitado. Alternativamente, la API podría utilizar una consulta de base de datos para verificar que el ID del perfil existe y está asociado con el ID de usuario, antes de procesar la solicitud.
También es importante considerar el uso de versiones en la API, para permitir cambios en la estructura de URL o la lógica del controlador sin romper los clientes existentes. Esto se puede lograr incluyendo un número de versión en la URL o utilizando versionado basado en tipos de medios.