Manipulación de la colección masiva a través de una API REST (RESTful)

Question

Me gustaría obtener algunos consejos sobre el diseño de una API REST que permitirá a los clientes agregar/eliminar grandes cantidades de objetos a una colección de manera eficiente.

A través de la API, los clientes necesitan poder agregar elementos a la colección y eliminar elementos de ella, así como manipular los elementos existentes. En muchos casos, el cliente querrá realizar actualizaciones masivas a la colección, p. agregando 1000 elementos y eliminando 500 artículos diferentes. Parece que el cliente debería poder hacer esto en una sola transacción con el servidor, en lugar de requerir 1000 solicitudes POST separadas y 500 DELETE.

¿Alguien tiene alguna información sobre las mejores prácticas o convenciones para lograr esto?

Mi pensamiento actual es que uno debería PONER un objeto que representa el cambio en el URI de la colección, pero esto parece estar en desacuerdo con el HTTP 1.1 RFC, lo que parece sugerir que los datos enviados en una solicitud PUT deben interpretarse de forma independiente a partir de los datos ya presentes en el URI. Esto implica que el cliente debería enviar una descripción completa del nuevo estado de la colección de una sola vez, que puede ser mucho más grande que el cambio, o incluso ser más de lo que el cliente sabría cuando realiza la solicitud.

Obviamente, me alegraría desviarme de la RFC si fuera necesario, pero preferiría hacer esto de una manera convencional si existe tal convención.

Answer 1

Debe usar AtomPub. Está específicamente diseñado para gestionar colecciones a través de HTTP. Incluso puede haber una implementación para su idioma de elección.

Answer 2

Para los POST, al menos, parece que debería poder enviar a una lista URL y hacer que el cuerpo de la solicitud contenga una lista de recursos nuevos en lugar de un único recurso nuevo.

Answer 3

Por lo que yo entiendo, REST significa REpresentational State Transfer, por lo que debe transferir el estado de cliente a servidor.

Si eso significa demasiados datos yendo y viniendo, quizás necesite cambiar su representación. Una estructura de cambio de colección funcionaría, con una serie de eliminaciones (por id) y adiciones (con representaciones embebidas xml completas), POSTed a una URL de interfaz de manejo. La implementación de la interfaz puede elegir su propio método para eliminaciones y adiciones en el lado del servidor.

La versión más pura probablemente sea definir los elementos por URL, y la colección contiene una serie de URL. La nueva colección puede ser PUT después de los cambios por parte del cliente, seguido de una serie de PUT de los elementos que se agregan, y tal vez una serie de eliminaciones si realmente desea eliminar los elementos del servidor en lugar de simplemente eliminarlos de esa lista.

Answer 4

Se podría introducir metarrepresentación de elementos de recogida existentes que no necesitan toda su estado transfirieron, por lo que en algún código abstracto de su actualización podría tener este aspecto:

{existing elements 1-100} 
{new element foo with values "bar", "baz"} 
{existing element 105} 
{new element foobar with values "bar", "foo"} 
{existing elements 110-200}

Adición (y modificación) elementos es hecho al definir sus valores, eliminar elementos se hace al no mencionarlo, la nueva colección y los elementos de reordenamiento se hacen especificando el nuevo orden (si el orden está almacenado).

De esta manera puede representar fácilmente toda la nueva colección sin tener que volver a transmitir todo el contenido. El uso de un encabezado If-Unmodified-Since asegura que su idea del contenido coincida con la idea de los servidores (para que no elimine accidentalmente los elementos que simplemente no sabía cuando se envió la solicitud).

Answer 5

Es posible que desee pensar en la tarea de cambio como un recurso en sí mismo. Entonces, realmente está PONIENDO un solo objeto, que es un objeto de Actualización masiva de datos. Tal vez tenga un nombre, propietario y gran cantidad de archivos CSV, XML, etc. que deben analizarse y ejecutarse. En el caso de CSV, es posible que también desee identificar qué tipo de objetos están representados en los datos CSV.

Enumere trabajos, agregue un trabajo, vea el estado de un trabajo, actualice un trabajo (probablemente para iniciar/detenerlo), elimine un trabajo (detenga si se está ejecutando), etc. Esas operaciones se asignan fácilmente a un Diseño de API REST.

Una vez que tenga esto en su lugar, puede agregar fácilmente diferentes tipos de datos que su actualizador de datos masivos puede manejar, tal vez incluso mezclados en la misma tarea. No es necesario tener esta misma API duplicada en toda su aplicación para cada tipo de cosa que quiera importar, en otras palabras.

Esto también se presta muy fácilmente a una implementación de tareas en segundo plano. En ese caso, probablemente desee agregar campos a los objetos de la tarea individual que permitan que el cliente de la API especifique cómo desean que se les notifique (una URL que desean que OBTENGA cuando esté terminada, o enviarles un correo electrónico, etc.) .

Answer 6

Sí, PUT crea/sobrescribe, pero no actualiza parcialmente.

Si necesita una semántica de actualización parcial, use PATCH. Ver http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-14.html.