Как моделировать операции файловой системы с REST?

Question

Существуют очевидные аналоги для некоторых основных операций файловых систем (например, ls и rm), но как бы вы реализовали не просто действия RESTful, такие как cp или mv?

В качестве ответа на вопрос Как реализовать копирование-вставку ресурса в REST? предлагает, предпочтительный способ реализации cp будет включать в себя получение ресурса, его удаление и повторное удаление с помощью новое имя.

Но что, если мне понадобится сделать это эффективно? Например, если размер ресурса будет огромным? Как бы я избавился от лишней передачи полезной нагрузки ресурса клиенту и обратно на исходный сервер?

Вот иллюстрация. У меня есть ресурс:

/videos/my_videos/2-gigabyte-video.avi

и я хочу скопировать его на новый ресурс:

/videos/johns_videos/copied-2-gigabyte-video.avi

Как бы я реализовал копирование, перемещение или другие действия файловой системы способом RESTful? Или есть даже правильный путь? Я все делаю неправильно?

Answer 1

Я не верю, что какой-либо из приведенных ответов ОТЛИЧНЫЙ. Вот что я бы сделал.

Для копирования:

PUT /videos/johns_videos/copied-2-gigabyte-video.avi
HOST: www.server.com
Content-Location: /videos/johns_videos/2-gigabyte-video.avi
[empty-body]

РАЗМЕСТИТЬ содержимое в месте (/videos/johns_videos/2-gigabyte-video.avi) в (/videos/johns_videos/copied-2-gigabyte-video.avi).

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

PUT /videos/johns_videos/copied-2-gigabyte-video.avi
HOST: www.server.com
Content-Location: /videos/johns_videos/2-gigabyte-video.avi
[empty-body]

    201 Created
    ETag: "3e32f5a1123afb12" (an md5 of the file)
    Location: /videos/johns_videos/copied-2-gigabyte-video.avi
    [empty-body]

DELETE /videos/johns_videos/2-gigabyte-video.avi
HOST: www.server.com
If-Match: "3e32f5a1123afb12"
[empty-body]

    204 No Content
    [empty-body]

Почему это RESTful?

• Не добавляет "перемещение" или "копирование" на URI (который является RPC)
• Используется PUT (POST - добавление к коллекции, целевой URI неизвестен полностью)
• Он не использует отправленные «команды» (например, инструкции XML), которые являются RPC, а не REST.
• Отсутствует понимание хранилища подчеркивания - клиент не заботится о жестких / программных ссылках или оптимизации при записи при копировании и никогда не должен знать о них.

Майк Браун

Answer 2

[... предпочтительный способ реализации CP будет включать в себя получение ресурса, УДАЛЯТЬ и снова ставить обратно с новым именем.]

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

Возможный подход:

• Если ресурсы являются документами (что, я думаю, они есть в вашем случае), я бы рассмотрел вариант использования WebDAV .
• Если WebDAV не вариант -
  • создать объект контроллера на сервере для управления операциями копирования и перемещения, клиент может POST что-то вроде / videos / my_videos / [video_id] / copy
  • В своем ответе вы можете указать URI для скопированного ресурса в строках:

HTTP / 1.1 201 Создано

Тип контента: видео / x-msvideo

Адрес: / видео / johns_videos / 8765

Примечание: Я предпочитаю возвращать идентификатор и работать с идентификаторами ресурсов, а не с чем-то вроде

Расположение: /videos/johns_videos/copied-2-gigabyte-video.avi

Операция перемещения очень похожа, за исключением того, что сервер может принять целевой ресурс. Пример:

http://example.com//videos/johns_videos/8765/move?destination=[destination]

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

Answer 3

Вы можете предоставить новый сервис, который использует (POST) простой документ XML, в котором указано, что вы хотите сделать.

<move>
   <target>/videos/my_videos/2-gigabyte-video.avi</target>
   <destination>/videos/johns_videos/copied-2-gigabyte-video.avi<destination>
<move>

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

Answer 4

REST не ограничивается HTTP! Лучшим способом было бы использовать webdav для вашей проблемы.

Answer 5

Один из способов сделать это - сформулировать ваши запросы PUT / POST так, чтобы вы могли либо указать фактические данные, либо указать URL-адрес ресурса, возможно, с возможностью сделать жесткую или символическую ссылку. Если данный URL-адрес размещен в вашей собственной системе, вы можете просто указать внутренне на тот же файл, возможно, оставив немного «копировать при записи» или что-то в этом духе, чтобы сделать его эффективным.

Answer 6

На мой взгляд, видео является ресурсом. Так что у этого ресурса есть путь. Что делать, если вы делаете ОБНОВЛЕНИЕ, которые изменяют путь ресурса?

Тогда в вашем коде, если он меняет путь, вам просто нужно переместить файл.