Creando una relación de entidad en REST: ¿Puedo crear el padre mediante la publicación en un ID de niño?

8

Actualmente estamos diseñando una API REST para acceder a datos de clientes clásicos. Uno de los elementos en la API son los activos de un usuario. Los activos se agregan bajo un servicio dado. La API de back-end solo agregará un activo a un usuario bajo un servicio dado. Por lo tanto, no hay una relación de usuario - activo, sino una relación de usuario - [Servicio] - activo.

Nuestro URI se verá así:

/users/{id}/assets/{id}/services/{id}

Los usos de la API conocerán el ID de activo y el ID de servicio para crear una nueva entrada. Con lo que estamos luchando es con la creación de esta relación.

Una forma sencilla sería publicar toda la relación en /users/{id}/assets/

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

pero en realidad no estamos creando un activo como podría indicar el URI, sino una relación servicio-activo.

Como alternativa, estamos considerando POST 'al URI que trata la relación, de esta manera:

POST /users/{id}/assets/{id}/service/{id}
{attribute1:"{var}", attribute2:"{var}"}

Pero en este caso, la ruta de recursos /users/{id}/assets/{id} no existirá antes de la POST y se creará como un efecto secundario.

¿POST'ing en una ruta de recursos que no existe todavía está permitido en absoluto?

Gracias por tus pensamientos,

Gerard.

    
pregunta maasg 29.04.2013 - 14:09

3 respuestas

3

Parece que estás sugiriendo que, siempre que un usuario publique por primera vez en una relación inexistente, lo creará como parte de la publicación.

Si está preguntando si este tipo de patrón de creación en acceso es un patrón de desarrollo válido y aceptable, la respuesta es sí, es válido y es un patrón bastante común de ver.

    
respondido por el blueberryfields 29.04.2013 - 16:25
2

Aquí hay varios puntos: Primero: No debe colocar el ID cuando cree un nuevo recurso ya que este ID ya podría existir, o puede ser el sistema que usa una técnica específica para generar el ID y lo está forzando a usar el suyo, y para proponerlo, el ID debe ser creado por el sistema, el atributo del encabezado de la ubicación debe establecerse en caso de que se cree un recurso, para obtener el feed back con el id generado.

Segundo: Su JSON no es correcto, tiene que lidiar con el servicio como otro objeto dentro del objeto de activo, así como en el servicio de URI de recursos "s", tiene que tratarlo como una matriz.

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

tiene que ser:

POST /users/{id}/assets    
{services:[{ attribute1:"var", attribute2:"var"}]}

Si vas a utilizar de esta manera

Tercero: No prefiero usar esta forma para la propuesta de diseño, si este caso falla, ¿cómo podría saber que falla al crear un activo o servicio?

    
respondido por el Bassem Reda Zohdy 04.09.2013 - 17:31
0

Aquí hay una línea diferente de pensamiento:

POST /relationships
{ relationship:${id}, asset:{id}, service:{id}, user:{id}, data:"some data" }

De esta manera, está definiendo las relaciones como un enlace de tres vías entre el activo, el servicio y el usuario, y no implica ninguna relación jerárquica

A continuación, puede recuperar una relación específica mediante:

GET /relationships?id="2144321"

o busque un subconjunto de relaciones por:

GET /relationships?user="43434"

o

GET /relationships?asset="12433"

La forma original no es incorrecta, pero este enfoque puede darle más flexibilidad sobre quién se usa.

    
respondido por el Michael Shaw 04.09.2013 - 18:51

Lea otras preguntas en las etiquetas