Какой самый RESTful способ обновить ресурс неидемпотентным способом? - PullRequest
Новая
       54

Какой самый RESTful способ обновить ресурс неидемпотентным способом?

0 голосов
/ 14 мая 2019

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

Я создаю Rest API, и я пришел к выбору дизайна, где я совершенно уверен в способе двигаться вперед.

У меня есть ресурс, который я хочуобновление, которое включает в себя создание большого BLOB-объекта JSON на основе данных поддержки, а затем сохранение этого BLOB-объекта в базу данных перед его отправкой обратно пользователю.

Мой вопрос заключается в том, как наиболее RESTful способ выполнить это действие?Поскольку клиент не выполняет вычисления, и он также не является идемпотентным, так как набор данных может меняться при каждом вызове, я чувствую, что использовать PUT неестественно.

Я остановился на POST, ноэто тоже не правильно.

Третий вариант - иметь подресурс, который описывает действие обновления - это тоже не правильно.

Например, у меня есть документ: 

GET /document/<documentId>

, который возвращает что-то вроде: 

"body": {
    "createdAt": "2019-01-01 12:00:00",
    "updatedAt": "2019-01-01 13:00:00",
    "name": "example",
    "location": "example",
    "city": "example"
}

Эти поля генерируются сервером при создании документа, клиент не обновляет их.

Чтобы разрешитьКлиент, чтобы сообщить, что он хотел бы, чтобы сервер обновил документ, я остановился на: 

POST /document/<documentId>
"body": {
   "param1": "updatedparam1",
   "param2": "updatedparam2"
}

Альтернативный подход будет сделать что-то вроде: 

POST /document/<documentId>/refresh
"body": {...}

, но это чувствуетбольше похоже на вызов RPC, а не на REST.

Имеет ли это логический смысл?Я не видел много предположений о том, что POST может относиться к одному ресурсу, а не к коллекции.

Пожалуйста, дайте мне знать, если я могу расширить что-нибудь, я бился головой об этомна некоторое время и, возможно, что-то пропустил.

1 Ответ

0 голосов
/ 14 мая 2019

Я остановился на POST, но это тоже не правильно.

POST штраф .

Семантика HTTP включает правила о аннулировании кэшированных представлений ресурсов. Предположительно, когда вы говорите серверу перегенерировать документ, вы не хотите продолжать использовать старую копию самостоятельно. Таким образом, целевой URI запроса должен совпадать с тем, который вы используете для GET ресурса.

Итак: 

POST /document/<documentId>

Хорошее начало.

Альтернативой, при условии совпадения семантики, будет использование PATCH - это правильный выбор, если вы предлагаете заменяющие значения для представления. В этом случае тело запроса должно быть «документом исправления». Вы, конечно, можете определить свой собственный тип документа патча; универсальные клиенты могут уже понимать один или несколько стандартов RFC-6902: JSON Patch или RFC-7386: JSON Merge Patch , поэтому вы можете потенциально сохранить часть работы, поддерживая один или несколько стандартные форматы.

Я не видел много предложений о том, что POST может быть для одного ресурса, а не для коллекции.

Часть REST заключается в том, что ресурсы поддерживают единый интерфейс - «отдельные ресурсы» и «ресурсы сбора» выглядят одинаково . Исторически нам немного не повезло с ранними спецификациями для POST , которые легко были неверно истолкованы как CREATE.

Но клиенты общего типа не знают или не заботятся о том, является ли ресурс, указанный вами в веб-форме, «ресурсом для сбора»; он просто упаковывает данные и отправляет запрос, будучи уверенным, что сервер будет знать, что делать.

...