Ваш язык "Это кажется очень расточительным ...", для меня указывает на попытку преждевременной оптимизации. Если нельзя доказать, что отправка всего представления объектов является серьезным ударом по производительности (мы говорим неприемлемо для пользователей, как> 150 мс), то нет смысла пытаться создать новое нестандартное поведение API. Помните, что чем проще API, тем проще его использовать.
Для удаления отправьте следующее, поскольку серверу не нужно ничего знать о состоянии объекта до того, как произойдет удаление.
DELETE /emails
POSTDATA: [{id:1},{id:2}]
Следующая мысль состоит в том, что если приложение сталкивается с проблемами производительности, связанными с массовым обновлением объектов, то следует рассмотреть возможность разбиения каждого объекта на несколько объектов. Таким образом, полезная нагрузка JSON является частью размера.
В качестве примера при отправке ответа для обновления статусов «чтение» и «архив» двух отдельных сообщений электронной почты вам необходимо будет отправить следующее:
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"]
}
]
Я бы разделил изменяемые компоненты электронной почты (чтение, архивирование, важность, метки) на отдельный объект, так как остальные (к теме, тексту) никогда не будут обновлены.
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"]}
]
Другой подход заключается в использовании PATCH. Чтобы явно указать, какие свойства вы намереваетесь обновить и что все остальные должны игнорироваться.
PATCH /emails
POSTDATA: [
{
id:1,
read:true,
archived:true
},
{
id:2,
read:true,
archived:false
}
]
Люди утверждают, что PATCH должен быть реализован путем предоставления массива изменений, содержащего: действие (CRUD), путь (URL) и изменение значения. Это может считаться стандартной реализацией, но если вы посмотрите на весь REST API, он не интуитивно понятен. Кроме того, в приведенной выше реализации GitHub реализовал PATCH .
Подводя итог, можно придерживаться принципов RESTful с пакетными действиями и при этом иметь приемлемую производительность.