¿Patrones para manejar operaciones por lotes en los servicios web REST?

¿Qué patrones de diseño probados existen para las operaciones por lotes en recursos dentro de un servicio web de estilo REST?

Estoy tratando de lograr un equilibrio entre los ideales y la realidad en términos de rendimiento y estabilidad. Tenemos una API en este momento donde todas las operaciones se recuperan de un recurso de lista (es decir: GET / user) o en una sola instancia (PUT / user / 1, DELETE / user / 22, etc.).

Hay algunos casos en los que desea actualizar un solo campo de un conjunto completo de objetos. Parece un desperdicio enviar la representación completa de cada objeto de un lado a otro para actualizar el campo.

En una API de estilo RPC, podría tener un método:

/mail.do?method=markAsRead&messageIds=1,2,3,4... etc. 

¿Cuál es el equivalente REST aquí? ¿O está bien comprometerse de vez en cuando? ¿Arruina el diseño para agregar algunas operaciones específicas donde realmente mejora el rendimiento, etc.? El cliente en todos los casos en este momento es un navegador web (aplicación javascript en el lado del cliente).

Un patrón RESTful simple para lotes es hacer uso de un recurso de colección. Por ejemplo, para eliminar varios mensajes a la vez.

DELETE /mail?&id=0&id=1&id=2

Es un poco más complicado actualizar por lotes los recursos parciales o los atributos de los recursos. Es decir, actualice cada atributo marcado como leído. Básicamente, en lugar de tratar el atributo como parte de cada recurso, lo trata como un depósito en el que colocar los recursos. Ya se publicó un ejemplo. Lo ajusté un poco.

POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]

Básicamente, está actualizando la lista de correo marcado como leído.

También puede usar esto para asignar varios elementos a la misma categoría.

POST /mail?category=junk
POSTDATA: ids=[0,1,2]

Obviamente, es mucho más complicado hacer actualizaciones parciales por lotes al estilo iTunes (por ejemplo, artista + albumTitle pero no trackTitle). La analogía del cubo comienza a romperse.

POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]

A la larga, es mucho más fácil actualizar un solo recurso parcial o atributos de recursos. Simplemente haga uso de un subrecurso.

POST /mail/0/markAsRead
POSTDATA: true

Alternativamente, podría usar recursos parametrizados. Esto es menos común en los patrones REST, pero está permitido en las especificaciones URI y HTTP. Un punto y coma divide parámetros relacionados horizontalmente dentro de un recurso.

Actualice varios atributos, varios recursos:

POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk

Actualice varios recursos, solo un atributo:

POST /mail/0;1;2/markAsRead
POSTDATA: true

Actualice varios atributos, solo un recurso:

POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk

La creatividad RESTful abunda.

En absoluto: creo que el equivalente REST es (o al menos una solución es) casi exactamente eso: una interfaz especializada diseñada para acomodar una operación requerida por el cliente.

Recuerdo un patrón mencionado en el libro de Crane y Pascarello Ajax in Action (un libro excelente, por cierto, muy recomendado) en el que ilustran la implementación de un tipo de objeto CommandQueue cuyo trabajo es poner en cola las solicitudes en lotes y luego publíquelos en el servidor periódicamente.

El objeto, si no recuerdo mal, esencialmente contenía una serie de "comandos", por ejemplo, para ampliar su ejemplo, cada uno un registro que contiene un comando "markAsRead", un "messageId" y tal vez una referencia a una devolución de llamada / controlador función - y luego de acuerdo con alguna programación, o con alguna acción del usuario, el objeto de comando se serializará y se publicará en el servidor, y el cliente manejará el consiguiente procesamiento posterior.

No tengo los detalles a mano, pero parece que una cola de comandos de este tipo sería una forma de manejar su problema; reduciría sustancialmente la conversación general y abstraería la interfaz del lado del servidor de una manera que podría encontrar más flexible en el futuro.

Actualización : ¡Ajá! Encontré un fragmento de ese mismo libro en línea, completo con ejemplos de código (¡aunque todavía sugiero recoger el libro real!). Eche un vistazo aquí , comenzando con la sección 5.5.3:

Esto es fácil de codificar, pero puede generar muchos bits muy pequeños de tráfico hacia el servidor, lo cual es ineficiente y potencialmente confuso. Si queremos controlar nuestro tráfico, podemos capturar estas actualizaciones y ponerlas en cola localmente y luego enviarlas al servidor en lotes a nuestro gusto. En la lista 5.13 se muestra una cola de actualización simple implementada en JavaScript. [...]

La cola mantiene dos matrices. queued es una matriz indexada numéricamente, a la que se agregan nuevas actualizaciones. sent es una matriz asociativa que contiene las actualizaciones que se han enviado al servidor pero que están esperando una respuesta.

Aquí hay dos funciones pertinentes: una responsable de agregar comandos a la cola ( addCommand) y otra responsable de serializar y luego enviarlos al servidor ( fireRequest):

CommandQueue.prototype.addCommand = function(command)
{ 
    if (this.isCommand(command))
    {
        this.queue.append(command,true);
    }
}

CommandQueue.prototype.fireRequest = function()
{
    if (this.queued.length == 0)
    { 
        return; 
    }

    var data="data=";

    for (var i = 0; i < this.queued.length; i++)
    { 
        var cmd = this.queued[i]; 
        if (this.isCommand(cmd))
        {
            data += cmd.toRequestString(); 
            this.sent[cmd.id] = cmd;

            // ... and then send the contents of data in a POST request
        }
    }
}

Eso debería ponerte en marcha. ¡Buena suerte!

Si bien creo que @Alex está en el camino correcto, conceptualmente creo que debería ser al revés de lo que se sugiere.

La URL es en efecto "los recursos a los que apuntamos", por lo tanto:

    [GET] mail/1

significa obtener el registro del correo con id 1 y

    [PATCH] mail/1 data: mail[markAsRead]=true

significa parchear el registro de correo con la identificación 1. La cadena de consulta es un "filtro", que filtra los datos devueltos desde la URL.

    [GET] mail?markAsRead=true

Así que aquí estamos solicitando todo el correo ya marcado como leído. Entonces, [PATCH] a este camino sería decir "parchear los registros ya marcados como verdaderos" ... que no es lo que estamos tratando de lograr.

Entonces, un método por lotes, siguiendo este pensamiento, debería ser:

    [PATCH] mail/?id=1,2,3 <the records we are targeting> data: mail[markAsRead]=true

Por supuesto, no digo que esto sea REST verdadero (que no permite la manipulación de registros por lotes), sino que sigue la lógica ya existente y en uso por REST.

Su lenguaje, " Parece muy derrochador ...", para mí indica un intento de optimización prematura. A menos que se pueda demostrar que enviar la representación completa de los objetos es un gran impacto en el rendimiento (estamos hablando de que los usuarios son inaceptables> 150 ms), entonces no tiene sentido intentar crear un nuevo comportamiento API no estándar. Recuerde, cuanto más simple es la API, más fácil es usarla.

Para las eliminaciones, envíe lo siguiente ya que el servidor no necesita saber nada sobre el estado del objeto antes de que ocurra la eliminación.

DELETE /emails
POSTDATA: [{id:1},{id:2}]

El siguiente pensamiento es que si una aplicación se encuentra con problemas de rendimiento con respecto a la actualización masiva de objetos, se debe considerar dividir cada objeto en varios objetos. De esa forma, la carga útil de JSON es una fracción del tamaño.

Como ejemplo, al enviar una respuesta para actualizar los estados de "lectura" y "archivado" de dos correos electrónicos separados, deberá enviar lo siguiente:

PUT /emails
POSTDATA: [
            {
              id:1,
              to:"someone@bratwurst.com",
              from:"someguy@frommyville.com",
              subject:"Try this recipe!",
              text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1t Mustard Powder",
              read:true,
              archived:true,
              importance:2,
              labels:["Someone","Mustard"]
            },
            {
              id:2,
              to:"someone@bratwurst.com",
              from:"someguy@frommyville.com",
              subject:"Try this recipe (With Fix)",
              text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1T Mustard Powder, 1t Garlic Powder",
              read:true,
              archived:false,
              importance:1,
              labels:["Someone","Mustard"]
            }
            ]

Separaría los componentes mutables del correo electrónico (leído, archivado, importancia, etiquetas) en un objeto separado, ya que los otros (para, desde, asunto, texto) nunca se actualizarían.

PUT /email-statuses
POSTDATA: [
            {id:15,read:true,archived:true,importance:2,labels:["Someone","Mustard"]},
            {id:27,read:true,archived:false,importance:1,labels:["Someone","Mustard"]}
          ]

Otro enfoque a tomar es aprovechar el uso de un PATCH. Para indicar explícitamente qué propiedades tiene la intención de actualizar y que todos los demás deben ignorarse.

PATCH /emails
POSTDATA: [
            {
              id:1,
              read:true,
              archived:true
            },
            {
              id:2,
              read:true,
              archived:false
            }
          ]

Las personas afirman que PATCH debe implementarse proporcionando una serie de cambios que contengan: acción (CRUD), ruta (URL) y cambio de valor. Esto puede considerarse una implementación estándar, pero si observa la totalidad de una API REST, es una aplicación no intuitiva. Además, la implementación anterior es cómo GitHub ha implementado PATCH .

En resumen, es posible adherirse a los principios RESTful con acciones por lotes y aún tener un rendimiento aceptable.

La API de Google Drive tiene un sistema realmente interesante para resolver este problema ( ver aquí ).

Lo que hacen es básicamente agrupar diferentes solicitudes en una Content-Type: multipart/mixedsolicitud, con cada solicitud completa individual separada por algún delimitador definido. Los encabezados y el parámetro de consulta de la solicitud por lotes se heredan de las solicitudes individuales (es decir Authorization: Bearer some_token) a menos que se anulen en la solicitud individual.

Ejemplo : (tomado de sus documentos )

Solicitud:

POST https://www.googleapis.com/batch

Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary


POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8


{
  "emailAddress":"example@appsrocks.com",
  "role":"writer",
  "type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary


POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8


{
  "domain":"appsrocks.com",
   "role":"reader",
   "type":"domain"
}
--END_OF_PART--

Respuesta:

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35


{
 "id": "12218244892818058021i"
}


--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35


{
 "id": "04109509152946699072k"
}


--batch_6VIxXCQbJoQ_AATxy_GgFUk--

Me sentiría tentado en una operación como la de su ejemplo para escribir un analizador de rango.

No es mucho problema hacer un analizador que pueda leer "messageIds = 1-3,7-9,11,12-15". Sin duda, aumentaría la eficiencia para las operaciones generales que cubren todos los mensajes y es más escalable.

Buena publicación. He estado buscando una solución por unos días. Se me ocurrió una solución mediante el uso de pasar una cadena de consulta con un grupo de ID separados por comas, como:

DELETE /my/uri/to/delete?id=1,2,3,4,5

... luego pasar eso a una WHERE INcláusula en mi SQL. Funciona muy bien, pero me pregunto qué piensan los demás de este enfoque.

Desde mi punto de vista, creo que Facebook tiene la mejor implementación.

Se realiza una única solicitud HTTP con un parámetro por lotes y uno para un token.

En lote se envía un json. que contiene una colección de "solicitudes". Cada solicitud tiene una propiedad de método (get / post / put / delete / etc ...) y una propiedad relative_url (uri del punto final), además, los métodos post y put permiten una propiedad "body" donde se actualizan los campos se envían .

Más información en: API por lotes de Facebook