Шаблони обробки пакетних операцій у веб-сервісах REST?

Які перевірені схеми дизайну існують для пакетних операцій над ресурсами в рамках веб-сервісу в стилі REST?

Я намагаюся досягти балансу між ідеалами та реальністю з точки зору продуктивності та стабільності. Зараз у нас є API, де всі операції отримують із списку ресурсів (тобто: GET / користувач) або в одному екземплярі (PUT / user / 1, DELETE / user / 22 тощо).

Є деякі випадки, коли ви хочете оновити одне поле цілого набору об’єктів. Здається дуже марно надсилати все представлення для кожного об'єкта вперед і назад для оновлення одного поля.

В API стилю RPC у вас може бути метод:

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

Який тут еквівалент REST? Або нормально йти на компроміси час від часу. Чи це зруйнує дизайн, щоб додати кілька конкретних операцій, де це дійсно покращує продуктивність тощо? Клієнтом у всіх випадках зараз є Веб-браузер (програма JavaScript на стороні клієнта).

Простий шаблон RESTful для пакетів - це використання ресурсу збору. Наприклад, щоб видалити відразу кілька повідомлень.

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

Дещо складніше пакетне оновлення часткових ресурсів або атрибутів ресурсу. Тобто оновіть кожен атрибут markAsRead. В основному, замість того, щоб атрибут розглядався як частина кожного ресурсу, ви розглядаєте його як відро, в яке потрібно розміщувати ресурси. Один приклад уже розміщено. Я його трохи коригував.

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

В основному ви оновлюєте список пошти, позначеної як прочитана.

Ви також можете використовувати це для віднесення декількох предметів до однієї категорії.

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

Очевидно набагато складніше робити часткові оновлення в стилі iTunes (наприклад, виконавця + albumTitle, але не trackTitle). Аналогія відра починає руйнуватися.

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

Зрештою, набагато простіше оновити окремий частковий ресурс або атрибути ресурсу. Просто скористайтеся підресурсом.

POST /mail/0/markAsRead
POSTDATA: true

Крім того, ви можете використовувати параметризовані ресурси. Це рідше в шаблонах REST, але дозволено в специфікаціях URI і HTTP. Точка з комою розділяє горизонтально пов'язані параметри всередині ресурсу.

Оновіть кілька атрибутів, кілька ресурсів:

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

Оновіть кілька ресурсів, лише один атрибут:

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

Оновіть кілька атрибутів, лише один ресурс:

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

ТВОРЧА творчість рясніє.

Зовсім не - я думаю, що еквівалент REST - це (або, принаймні, одне рішення) майже саме це - спеціалізований інтерфейс, розроблений для розміщення операцій, необхідних клієнту.

Мені нагадали зразок, згаданий у книзі Крейн та Паскарелло « Ajax in Action» (відмінна книга, до речі, настійно рекомендується), в якій вони ілюструють реалізацію подібного об’єкта CommandQueue , завданням якого є встановлення черги на запити в партії та потім періодично публікуйте їх на сервері.

Якщо я добре пам’ятаю, об’єкт, по суті, просто містив масив «команд» - наприклад, для розширення вашого прикладу, кожен з яких містить запис, що містить команду «markAsRead», «messageId» і, можливо, посилання на зворотний виклик / обробник функція - і тоді згідно з деяким графіком або за деякими діями користувача, об'єкт команди буде серіалізований і розміщений на сервері, а клієнт обробляв би наступну післяобробну обробку.

У мене не трапляються деталі під рукою, але це здається, що черга команд такого роду була б одним із способів вирішити вашу проблему; це суттєво знизить загальну балаканину, а також абстрагує інтерфейс на стороні сервера таким чином, що ви можете виявити більш гнучким у дорозі.

Оновлення : Ага! Я знайшов фрагмент цієї книги в Інтернеті разом із зразками коду (хоча я все ж пропоную підібрати фактичну книгу!). Подивіться тут , починаючи з розділу 5.5.3:

Це легко кодувати, але може призвести до великої кількості дуже малих бітів трафіку до сервера, що є неефективним та потенційно заплутаним. Якщо ми хочемо контролювати наш трафік, ми можемо зафіксувати ці оновлення та встановити їх у черзі локально, а потім відправити їх на сервер партіями в наше дозвілля. Проста черга на оновлення, реалізована в JavaScript, показана в списку 5.13. [...]

Черга підтримує два масиви. queued - це числовий індексований масив, до якого додаються нові оновлення. sent це асоціативний масив, що містить ті оновлення, які були надіслані на сервер, але чекають відповіді.

Ось дві відповідні функції - одна відповідає за додавання команд у чергу ( addCommand), а одна відповідає за серіалізацію та потім їх відправлення на сервер ( 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
        }
    }
}

Це повинно вас змусити йти. Удачі!

Хоча я думаю, що @Alex йде по правильному шляху, концептуально я думаю, що він повинен бути зворотним для запропонованого.

URL по суті "ресурси, на які ми орієнтуємось", отже:

    [GET] mail/1

означає отримати запис з пошти з id 1 і

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

означає, виправити запис пошти за допомогою ідентифікатора 1. Рядок запитів - це "фільтр", фільтруючи дані, повернені з URL-адреси.

    [GET] mail?markAsRead=true

Тому тут ми просимо всю пошту, вже позначену як прочитану. Отже, щоб [PATCH] на цей шлях означав би "виправити записи, вже позначені як істинні" ... чого ми не прагнемо досягти.

Отже, пакетним методом слід дотримуватися цього мислення:

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

Звичайно, я не кажу, що це правда REST (що не дозволяє маніпулювати записом пакетних записів), скоріше це слід за логікою, яка вже існує та використовується REST.

Ваша мова "Це здається дуже марною ..." для мене вказує на спробу передчасної оптимізації. Якщо не може бути показано, що надсилання всього представлення об'єктів є головним ударом (ми говоримо неприйнятно для користувачів, як> 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 за допомогою пакетних дій і все ще мати прийнятну продуктивність.

API диска google має дійсно цікаву систему для вирішення цієї проблеми ( див. Тут ).

Вони в основному групують різні запити в одному Content-Type: multipart/mixedзапиті, при цьому кожен окремий повний запит розділяється певним розмежувачем. Параметри заголовків і запитів пакетного запиту успадковуються окремим запитам (тобто Authorization: Bearer some_token), якщо вони не перекрито в індивідуальному запиті.

Приклад : (взяті з їхніх документів )

Запит:

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--

Відповідь:

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--

Я б спокусився в такій операції, як у вашому прикладі, щоб написати аналізатор діапазону.

Не зайвим буде зробити аналізатор, який може читати "messageIds = 1-3,7-9,11,12-15". Це, безумовно, збільшить ефективність для покривних операцій, що охоплюють усі повідомлення, і є більш масштабованою.

Чудовий пост. Я шукав рішення кілька днів. Я придумав рішення, як використовувати передачу рядка запиту з куповими ідентифікаторами, розділеними комами, як-от:

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

... передаючи це до WHERE INпункту мого SQL. Це чудово працює, але дивуйтеся, що інші думають про цей підхід.

З моєї точки зору, я думаю, що у Facebook є найкраща реалізація.

Один HTTP-запит робиться з параметрами batch та одним для маркера.

У партії відправляється json. який містить колекцію "запитів". Кожен запит має властивість методу (get / post / put / delete / тощо ...), а також властивість Rela_url (uri кінцевої точки), додатково методи публікації та put дозволяють властивості "body", де поля оновлюються відправляються.

докладнішу інформацію на: Facebook batch API