Seu idioma, " Parece muito inútil ...", para mim indica uma tentativa de otimização prematura. A menos que seja possível demonstrar que o envio de toda a representação de objetos é um grande problema de desempenho (estamos falando inaceitáveis para usuários com mais de 150 ms), não faz sentido tentar criar um novo comportamento de API não padrão. Lembre-se, quanto mais simples a API, mais fácil é usar.
Para exclusões, envie o seguinte, pois o servidor não precisa saber nada sobre o estado do objeto antes que a exclusão ocorra.
DELETE /emails
POSTDATA: [{id:1},{id:2}]
O próximo pensamento é que, se um aplicativo estiver enfrentando problemas de desempenho relacionados à atualização em massa de objetos, deve-se considerar a possibilidade de dividir cada objeto em vários objetos. Dessa forma, a carga útil JSON é uma fração do tamanho.
Como exemplo, ao enviar uma resposta para atualizar os status "lido" e "arquivado" de dois emails separados, você deverá enviar o seguinte:
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"]
}
]
Eu dividiria os componentes mutáveis do email (lidos, arquivados, importantes, marcadores) em um objeto separado, pois os outros (para, de, assunto, texto) nunca seriam atualizados.
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"]}
]
Outra abordagem a ser adotada é aproveitar o uso de um PATCH. Para indicar explicitamente quais propriedades você pretende atualizar e que todas as outras devem ser ignoradas.
PATCH /emails
POSTDATA: [
{
id:1,
read:true,
archived:true
},
{
id:2,
read:true,
archived:false
}
]
As pessoas afirmam que PATCH deve ser implementado fornecendo uma matriz de alterações contendo: ação (CRUD), caminho (URL) e alteração de valor. Isso pode ser considerado uma implementação padrão, mas se você analisar a totalidade de uma API REST, é uma ocorrência não intuitiva. Além disso, a implementação acima é como o GitHub implementou o PATCH .
Para resumir, é possível aderir aos princípios RESTful com ações em lote e ainda ter um desempenho aceitável.