Переместить ресурс в архитектуре RESTful

Question

У меня есть веб-сервис RESTful, который представляет процессы и действия. Каждое действие находится внутри одного и только одного процесса. Я хотел бы представить операцию перемещения между процессом, в котором он находится в данный момент, и другим процессом.

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

Есть идеи?

Answer 1

Одним из способов может быть представление самого перемещения как, скажем, ресурса «переноса» (передача в качестве существительного) и POST нового:

POST /transfer

С сущностью, содержащей:

activity: /activities/4
toProcess: /processes/13

Таким образом, клиенты создают новые «переводы», которые на сервере обрабатывают проверку и перенос действия.

Это также дает вам возможность добавлять информацию о переносе.Если вы хотите сохранить историю аудита, вы можете добавить к ресурсу свойство transferredBy или дату transferredOn.

Answer 2

Если вы используете PUT, вы можете определить разницу по тому, соответствует ли процесс существующего объекта новому.

PUT /process1/activity2

process: 2
some_data: and_stuff

На что логический ответ (в случае успеха) равен

303 See Other
Location: /process2/activity2

Answer 3

Учитывая доступные ответы, я не очень доволен предложениями.

POST - это универсальный метод, который следует использовать, если ни одна из других операций не отвечает требованиям.Семантика полученной полезной нагрузки определяется только службой / API и, следовательно, может быть решением для одного API, но не для большинства.Кроме того, ему не хватает свойства идемпотентности, которое в случае сетевой проблемы оставляет клиента в неопределенности относительно того, получил ли запрос сервер, и только ответ был потерян в середине пути, или если запрос вообще не достиг сервера.Следовательно, последовательный запрос может привести к неожиданным результатам или дальнейшим действиям.

PUT имеет семантику замените текущее представление, полученное из ресурса (может быть пустым), на представлениепредоставляется в полезной нагрузке .Серверы могут модифицировать полученное представление для более подходящего, добавлять или удалять дополнительные данные.PUT может даже иметь побочные эффекты и на других ресурсах, т. Е. Если предусмотрен механизм управления версиями для обновления документа.Предоставляя вышеупомянутое свойство idempotency, PUT фактически не соответствует семантике запрошенного действия.Это может иметь серьезные последствия для совместимости, поскольку стандартные HTTP-серверы не смогут правильно вас обслуживать.

Можно использовать комбинацию POST, чтобы сначала создать новое представление на новой конечной точке, а затем удалить старую.один через DELETE.Тем не менее, это две отдельные операции, в которых первая операция может завершиться неудачно и, если ее неправильно обработать, приведет к немедленному удалению исходного ресурса в худшем случае.К сожалению, в этом наборе операций нет реального транзакционного поведения.

Вместо использования вышеупомянутых операций я бы предложил использовать PATCH .PATCH является серьезным из изменений, рассчитанных клиентом, необходимых для преобразования текущего представления в желаемое.Сервер, поддерживающий PATCH, должен будет применять эти инструкции атомарно.Либо все они применяются, либо ни один из них вообще.PATCH может иметь побочные эффекты и, таким образом, в настоящее время наиболее подходит для выполнения перемещения по HTTP.Однако для правильного использования этого метода необходимо использовать определенные типы носителей.Можно ориентироваться на JSON Patch ( более удобный для чтения ), т. Е. Хотя это определяет только семантику операций для изменения состояния представлений на основе JSON и не имеет дело с несколькими ресурсами AFAIK.