Creación de una relación de entidad en REST: ¿Puedo crear el padre publicando en un ID hijo?

Actualmente estamos diseñando una API REST para acceder a los datos clásicos de los clientes. 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 en un servicio determinado. Por lo tanto, no hay una relación Usuario - Activo, sino una relación Usuario - [Servicio] - Activo.

Nuestros URI se verán así:

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

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

Una forma directa sería publicar toda la relación con /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 de servicio de activos.

Como alternativa, estamos considerando POST'ing al URI que aborda la relación, así:

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

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

¿POST'ing a una ruta de recursos que aún no existe está permitido?

Gracias por tus pensamientos

Gerard

Parece que estás sugiriendo que, cada vez que un usuario publica por primera vez en una relación inexistente, la crearás 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 para ver.

Aquí hay varios puntos: Primero: no debe poner la identificación al crear un nuevo recurso, ya que esta identificación ya podría existir, o puede ser el sistema que utiliza una técnica específica para generar la identificación y la está obligando a usar la suya, y para propongamos que el sistema debe crear el id. El atributo del encabezado de ubicación debe establecerse en el caso de un recurso de creación, para recuperar el feed con el id generado.

Segundo: su JSON no es correcto, debe tratar con el servicio como otro objeto dentro del objeto activo, así como en el servicio URI del recurso "s" debe 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 usar de esta manera

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

Aquí hay una línea de pensamiento diferente:

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

De esta manera, define las relaciones como un vínculo de tres vías entre activos, servicios y usuarios y no implica ninguna relación jerárquica.

Luego puede recuperar una relación específica de la siguiente manera:

GET /relationships?id="2144321"

o busque un subconjunto de relaciones por:

GET /relationships?user="43434"

o

GET /relationships?asset="12433"

La forma original no está mal, pero este enfoque puede darle más flexibilidad sobre a quién se acostumbra.