Какой HTTP-глагол мне следует использовать для запроса и блокировки элемента в очереди заданий?

Question

Я планирую использовать интерфейс HTTP REST для подключения к сервису Job Control.

Одной из ключевых операций является запрос вычислительного задания.

• Абонент не знает идентификатор задания; это то, что будет сказано.
• Задание будет помечено в базе данных как заблокированное службой.
• Данные, необходимые для обработки задания, будут возвращены вызывающей стороне.

Позже, когда абонент завершит обработку задания, он отправит результаты обратно с помощью другого вызова REST.

• Теперь он знает идентификатор записи, которая должна быть обновлено.
• Второй вызов REST обновит запись задания с результатами.
• , изменит статус задания и снимет блокировку.
• Требуется только статус Успешно / Сбой должен быть возвращен.

Я склоняюсь к использованию PUT для каждой операции, потому что не создается новая запись; оно обновляется в обоих случаях.

Это правильно? Может ли первый PUT вернуть большую JSON полезную нагрузку с данными задания или он просто возвращает HTTP-статус? Должен ли я вместо этого использовать POST, даже если я не создаю запись, а просто обновляю ее?

Я бы использовал GET для первой операции, но GET не должен изменять какие-либо объекты в службе и я его блокирую, что является изменением. Допустима ли блокировка записи в GET-запросе?

Answer 1

Какой HTTP-глагол мне следует использовать для запроса и блокировки элемента в очереди заданий?

Основная идея: REST API - это фасад - ваше приложение / служба претендует на то, чтобы быть HTTP-совместимое хранилище документов. Все интересные вещи, которые случаются побочные эффекты , вызваны изменением документов. См. Джим Уэббер, 2011 .

Имея это в виду ...

POST - это хорошо. Можно использовать POST .

PUT / PATCH хороши для удаленной авторизации; клиент выбирает ваше представление ресурса, вносит изменения в его локальную копию и отправляет вам копию представления (PUT) или документ исправления, описывающий изменения (PATCH). Затем сервер может применить эти изменения к своей копии или нет.

Так что для вашего конкретного примера c я бы ожидал, что клиент GET представит ваш ресурс, изменит информацию в этом представлении. от разблокированного к заблокированному, а затем, чтобы положить измененное представление обратно на ваш сервер. Ожидается, что ваш сервер обновит вашу копию представления для соответствия.

Это может напомнить вам о декларативном стиле - клиент сообщает серверу, как должно выглядеть представление, и это зависит от сервера, чтобы определить Как это сделать.

Включено для полноты, НЕ РЕКОМЕНДУЕТСЯ:

В реестре HTTP-метода также имеется метод LOCK с соответствующим ОТКРЫТЬ. Семантика для этих токенов метода определяется спецификацией WebDAV . Если ваше значение LOCK совпадает со значением WebDAV, то использование этого может быть ответом. Обратите внимание, что в спецификации содержатся комментарии, такие как

. Любой ресурс, поддерживающий метод LOCK, ДОЛЖЕН, как минимум, поддерживать форматы запросов и ответов XML, определенные в данном документе.

вы уже находитесь в пространстве, где люди ожидают, что смогут использовать клиенты WebDAV общего назначения для взаимодействия с вашим API, что, вероятно, не очень подходит.

Реестр метода HTTP: extendedable . Таким образом, вы можете определить семантику вашего собственного токена метода, а затем pu sh, чтобы он был принят в качестве стандарта.