¿Está bien cambiar parcialmente una colección con PUT o DELETE?

Tengo una colección de productos en un grupo de productos, por ejemplo:

product-groups/123/products

1. Si necesito agregar a la colección, ¿está bien que solo pase algunos productos con PUT?

2. Si necesito eliminar algunos productos de la colección, ¿está bien que pase los datos del filtro (una matriz de ID) con DELETE?

¿Cuál es la mejor manera de implementar la funcionalidad en el espíritu de ReST?

Editar: los artículos son enlaces a entidades separadas, básicamente identificaciones de productos.

En general, tiene un punto final que representa la colección completa de x :

/products

Por ejemplo, quieres actualizar un solo producto, se hace un PUT a /products/{id}. Si desea actualizar parcialmente un solo producto (sin actualizar todos los campos), también puede usar un PATCH para /products/{id}. Lo mismo ocurre con la eliminación de una sola entidad ( DELETE to /products/{id}).

Si desea apuntar a un único recurso, califique a través de la ruta, qué recurso único desea modificar.

La única acción que rompe el esquema es la creación de un recurso. Cuando cree un recurso, apunte a la colección como un todo, diga POST a /products.

Dicho esto, debe quedar claro, que el objetivo para las operaciones que afectan a la colección en su conjunto, debe ir al punto final de recolección apropiado.

Por ejemplo, si desea recuperar un subconjunto de productos que son rojos, lo solicita

GET a /products?colour=red.

Entonces, si desea eliminar todo esto, BORRAR /products?colour=red . O si desea eliminar algunos de los productos mediante id, puede ELIMINAR /products?id=1&id=2&id=3 .

¿Qué pasa con la creación masiva de recursos? PUBLICA tu colección [{...},{...},{...}]simplemente en /products. Lo mismo aplica para PUT y PATCH .

Eso es realmente sencillo.

Para responder tu pregunta:

Si necesito agregar a la colección, ¿está bien que solo pase algunos productos con PUT?

No solo está bien, le recomendamos que lo haga así.

Si necesito eliminar algunos productos de la colección, ¿está bien que pase los datos del filtro (una matriz de ID) con DELETE?

Eso está bien. Como escribió Eneko Alonso, a veces hay operaciones masivas encapsuladas a través de puntos finales "controladores", es decir, se utiliza una POST para desencadenar operaciones (complejas).

Por lo general, los métodos REST están destinados a operar en una sola entidad / objeto (CRUD).

Hay varias opciones:

• Trate sus colecciones como entidades y actualícelas a través de POST
• Crear operaciones alternativas que no sean REST

El primero sigue los estándares REST, pero puede ser costoso, ya que los objetos / entidades de su colección pueden ser muy grandes (actualizar un grupo que tiene miles de productos solo para agregar / eliminar un producto sería una gran solicitud).

La segunda opción es preferida por muchas API, como una forma de extender REST más allá de las operaciones CRUD.

Por ejemplo:

GET product-groups/123/products (list all the products in the group)
POST product-groups/123/products/append (POST a list of new product ids to append to the group)
POST product-groups/123/products/remove (POST a list of product ids to remove from the group)

Muchas API usan siempre POST para estas operaciones extendidas, pero nada lo limita a usar otros métodos http (aparte de la limitación de GET y DELETE para tener un cuerpo vacío)

Solo para precisar respuestas / comentarios anteriores.

Según mi conocimiento, POST es el método para agregar elementos individuales a la colección.

DELETE a su vez, es el método para eliminar un solo elemento de la colección. Ambos escenarios son perfectamente RESTful.

Sin embargo, debe usar el URI apropiado para referir un solo elemento o la colección completa.

Por ejemplo, para agregar un elemento a la colección, debe PUBLICAR datos en el siguiente URI:

https://www.factory.net/products/

Para eliminar un solo producto de la colección, puede usar el método DELETE enviando solicitud a algo como:

https://www.factory.net/products/108/

El método PATCH puede usarse para actualizar algunos elementos dentro de la colección. Por ejemplo, cuando solo necesita actualizar un campo en un elemento. PONER una representación completa de recursos para una colección muy grande puede ser una operación muy costosa.

En principio, todas las operaciones RESTful son válidas en una colección, pero asegúrese de comprender cómo se aplica la semántica de los verbos a una colección:

• PUT es un reemplazo completo .

  • Si pone un singleton (p /item/{id}. Ej. ) Y lo deja namefuera, debe borrarse o establecerse en nulo o algo similar.
  • Si PONE a una colección y no incluye un artículo, debe eliminarse de esa colección.

  Si bien se puede usar un PUT para agregar elementos, debe enviar "todos" los elementos. El envío de "algunos" elementos debería resultar en la eliminación (supongo que esto no es lo que desea el OP).

• ELIMINAR es más intuitivo. Es válido eliminar la colección o cualquier subconjunto filtrado de la misma. Solo los elementos incluidos en el filtro deben verse afectados.

• PARCHE también es válido. En teoría, se supone que debe proporcionar una lista de "operaciones". Por ejemplo, técnicamente debería enviar algo como:

  [{ 
      "action": "update",
      "id": <id>,
      "value": {...}
  },{
      "action": "add",
      "value": {...}
  }, ...]
  

  En la práctica, es más común ver una API que acepta una lista parcial de objetos donde cada elemento se procesa utilizando una lógica UPSERT (actualización o inserción).

• Técnicamente, POST debe procesar la entrada "de acuerdo con la semántica específica del recurso".

  • En la práctica, POST se usa normalmente para operaciones de "creación".
  • Sin embargo, POST también es el verbo utilizado para llamadas no estándar. Si bien existe un debate vigoroso sobre si los puntos finales de acción son estrictamente RESTful (estoy del lado de los "no"), POST es el verbo apropiado si estaba enviando una solicitud a un punto final como {resource}/activate.

NOTA: Cuando utilice operaciones que no sean GET en colecciones, considere cuidadosamente la definición de éxito y fracaso. REST no le brinda una buena forma de comunicar el éxito parcial. Un buen valor predeterminado es asumir que ejecutará la operación en una transacción con un criterio de éxito de todo o nada. Si esto no es lo que desea, probablemente no debería estar interactuando directamente con la colección.