Buscando un enfoque RESTful para actualizar múltiples recursos con el mismo conjunto de campos

Question

La tarea: Tengo varios recursos que deben actualizarse en una llamada HTTP.

El tipo de recurso, el campo y el valor para actualizar son los mismos para todos los recursos.

Ejemplo: tienen un conjunto de autos por sus ID, necesitan actualizar el "estado" de todos los autos a "vendido".

clásico enfoque reparador: solicitud de uso de URL como algo PUT/coches con el cuerpo como JSON [{id: 1, estado: vendido}, {id: 2, Estado: vendido}, ... ]

Sin embargo, esto parece ser una exageración: demasiadas veces para poner estado: vendido

busca de un modo REST (me refiero a la forma en que está tan cerca de protocolo de reposo "estándar" como sea posible) para enviar el estado : vendido solo una vez para todos los automóviles junto con la lista de identificadores de automóviles para actualizar. Esto es lo que haría:

PUT/coches Con JSON {ids = [1,2, ...], estado: vendido}, pero no estoy seguro de si esto es realmente el enfoque REST .

¿Alguna idea?

también como un beneficio adicional: Me gustaría ser capaz de evitar JSON para pequeño número de coches simplemente la creación de una dirección URL con parámetros algo como esto:?

PUT/identificadores de coches = 1,2 , 3 & estado = vendido

¿Es esto lo suficientemente RESTANTE?

Answer 1

Una forma aún más simple sería simplemente:

{sold:[1,2,...]} 

No hay necesidad de tener múltiples métodos para números mayores o menores de solicitudes - se desperdicia el tiempo de desarrollo y no tiene un impacto notable en el rendimiento o ancho de banda.

Por lo que respecta a RESTful goes, siempre que el destinatario pueda descifrarlo fácilmente y contenga toda la información que necesita, no hay problema.

Answer 2

Según tengo entendido, usar put no es suficiente para escribir una sola propiedad de un recurso. Una idea es simplemente exponer la propiedad como un recurso en sí:

Por lo tanto: PUT/car/carId/status con el contenido del cuerpo 'Vendido'.

La actualización de más de un automóvil debería dar lugar a múltiples puts, ya que una solicitud solo debería tener como objetivo un único recurso.

Otra idea es exponer un cierto protocolo donde se crea un recurso 'por lotes'.

contenido

de POST/diario-ofertas-informe/body { "vendido": [1, 2, 3, 4, 5]}

A continuación, el sistema simplemente puede reconocer las ofertas se está realizando y actualizar el estado de los coches sí mismo. De esta forma, puedes crear un punto de vista completamente nuevo y habilitar un API más REST que tu intención real.

También deberías pensar en exponer un recurso con una lista de todos los automóviles que están disponibles y por lo tanto están listos para ser vendidos (por lo tanto, no se venden, no necesitan reparaciones o no se alquilan).

GET/cars/pricelist? City = * -> Lista de todos los coches listos para ser vendidos, incluyendo la id del coche y el precio.

De esta manera, un automóvil no tiene un estado con respecto a quién es el dueño del automóvil. Un recurso por lo general es independiente de su propietario (el propietario no agrega los autos a los autos).

Cuando tiene dificultades para asignar una operación a un recurso, su modelo tiende a ser defectuoso por el pensamiento orientado a objetos. Con los recursos, muchas relaciones (propiedad principal) y propiedades de estado tienden a estar fuera de lugar, ya que el diseño de recursos es incluso más abstracto que pensar en los servicios.

Si necesita manipular muchos objetos similares, debe identificar el proceso comercial que desencadena esos cambios y exponer este proceso mediante un único recurso que describa su entrada (al igual que el informe de ofertas diarias).