framework - Crear entidades vinculadas en la API REST en Symfony
symfony rest framework (2)
¿Cuál es la forma correcta de crear una entidad que estará vinculada a otras? No encuentro ninguna fuente sobre cómo se debe hacer o cómo se hace en Symfony con el paquete FOSRestBundle.
Fondo:
Permite tener entidad Car con entidades de Wheel.
¿Cómo crear un automóvil con ruedas en una sola solicitud?
url: foo.com/cars POST
datos: {car:{name="porsche", wheels:[{name:"fr"}, {name:"fl"}] }}
¿Es esta la manera correcta de hacerlo? Leí algo acerca de los métodos HTTP LINK y UNLINK, pero eso necesitaría enviar múltiples solicitudes para crear todas las ruedas y luego unirlas.
¿Cómo crear rueda con pertenece a varios autos?
url: foo.com/wheels POST
data: {wheel:{name="super wheel", cars:[{id:1}, {id:2}] }}
En esta situación, tal vez usar el encabezado LINK sería apropiado. Pero después de leer este artículo, sería necesario analizar los encabezados LINK de todos los POSTS y PUTS también, lo que lo haría caro y voluminoso.
EDITAR
Le escribí al autor del artículo mencionado. Aquí está su respuesta:
Creo que puedes enviar datos que contengan tanto tus ruedas como tus autos en una sola solicitud. Lo más importante aquí es ser pragmático. No hay reglas "claras" para construir API REST.
LINK / UNLINK son útiles cuando los recursos ya existen, y desea "vincularlos", en otras palabras, desea agregar una "relación" entre ellos, como la amistad para los usuarios, por ejemplo.
Sobre su segunda pregunta, si los autos existen, primero puede crear su rueda y "vincularla" a sus automóviles. Pero significaría dos solicitudes para esta acción (puede agregar múltiples encabezados de enlace en una solicitud), o mejor podría enviar una solicitud POST con encabezados de enlace: una solicitud para controlarlos a todos: p
Otra opción sería hacer referencia a los identificadores de los autos en los datos de tu rueda. Creo que está bien hacer eso también.
Como lo citó: "No hay reglas" claras "para construir API REST".
Usualmente uso un formulario para validar mis datos en mi API, por lo tanto, ya tengo mis parámetros. Utilizo esto porque, tengo que escribir solo un punto final (usado tanto en forma de API, como también puede representar interfaces html). El formulario podría esperar una ID, o un subobjeto (o ambos).
No digo que debas usar mi punto de vista. Pero estoy diciendo: su API, sus reglas (depende del cliente adaptarse, pero también tiene que pensar como cliente para construir su API).
Hemos tenido la misma discusión recientemente.
Hay algo que decir acerca de la claridad y la arquitectura limpia donde separamos nuestros recursos de las relaciones, etc. También hay algo que decir para no hacer 1000 solicitudes y para armar cosas que pertenecen juntas.
Nuestra solución final fue muy parecida a la tuya. La otra solución sería nunca incluir relaciones en los recursos al insertarlos, y tener un punto final API separado para crear relaciones (por ejemplo, POST / cars / 1 / wheels / fl)
La forma de ir depende principalmente de la lógica de su dominio y de los requisitos de la aplicación. Tan pronto como tengas relaciones m: n circulares, tendrás grandes problemas con el enfoque que tú (y nosotros) elegimos. Para relaciones más simples y jerárquicas, es una manera perfectamente buena de hacerlo.