Какой HTTP-глагол я должен использовать для запуска действия в веб-службе REST?

Я реализую веб-службу RESTful, и одним из доступных действий будет reload. Он будет использоваться для перезагрузки конфигураций, кеша и т. Д.

Мы начали с простого GET в URI следующим образом: ${path}/cache/reload (параметры не передаются, вызывается только URI). Я знаю, что данные не должны быть изменены с помощью запроса GET.

Какой правильный глагол использовать для вызова действия /команды в веб-службе RESTful?

EDIT: перезагрузка - это команда веб-службы REST, которая перезагружает свой собственный кеш /конфигурацию /etc. Это не метод, который возвращает информацию клиенту.

FINAL EDIT: Возможно, что я пытаюсь сделать, это не REST, но все равно что-то нужно сделать таким образом. Метод reload был только реальный пример, который имеет смысл в области применения и большинства ответов, сфокусированных на нем, но на самом деле мне просто нужно было знать, какой глагол запускать действие, которое не выполняет CRUD, но все же изменяет данные /состояние.

Я нашел этот подробный asnwer в Stack Overflow для темы: https://stackoverflow.com/questions/16877968/

51 голос | спросил Renato Dinhani 2 72014vEurope/Moscow11bEurope/MoscowSun, 02 Nov 2014 04:17:34 +0300 2014, 04:17:34

9 ответов


17

Я не думаю, что для этого действия существует правильный глагол, потому что эта транзакция на самом деле не «RESTful». «S» и «t» означают «передачу состояния», и здесь ничего не передается. Или, по-другому, самым строгим определением, глаголы, такие как PUT и POST, всегда используются с существительным, а «перезагрузка» имеет только глагол.

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

ответил Sean Redmond 2 72014vEurope/Moscow11bEurope/MoscowSun, 02 Nov 2014 07:15:45 +0300 2014, 07:15:45
47

Если вы хотите быть RESTful, не думайте о глаголе, чтобы выполнить действие, подумайте о состоянии , в котором вы хотите, чтобы ресурс находился после того, как клиент что-то сделал.

Итак, используя один из приведенных выше примеров, у вас есть очередь электронной почты, отправляющая электронные письма. Вы хотите, чтобы клиент поставил эту очередь электронной почты в состояние приостановленной или остановленной или что-то еще.

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

PUT http://myserver.com/services/email_service HTTP/1.1
Content-Type: text/json

{"status":"paused"}

Сервер определяет, как перейти от текущего состояния (скажем, «работает») к «приостановленному» статусу /состоянию.

Если клиент выполняет GET на ресурсе, он должен вернуть состояние, в котором он сейчас находится (скажем, «приостановлено»).

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

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

Итак, вы можете полностью переписать /перепроектировать, как это делает сервер, и клиенту все равно. Клиент должен знать только о разных состояниях (и их представлениях) ресурса, а не о внутренних компонентах.

ответил Cormac Mulhall 3 12014vEurope/Moscow11bEurope/MoscowMon, 03 Nov 2014 18:22:14 +0300 2014, 18:22:14
21

Некоторые другие ответы, в том числе принятые, советуют использовать GET (хотя и не очень с энтузиазмом).

Я не согласен.

Прежде всего, все остальные говорят вам, что это не идеально, а не действительно RESTful. В правильном сценарии RESTful вы управляете ресурсами на сервере и добавляете, обновляете, удаляете, извлекаете и т. Д. Эти ресурсы. PUT должен отправить полезную нагрузку, которая представляет, каким должен быть ресурс, когда запрос будет завершен, а POST должен отправить полезную нагрузку, которая представляет ресурс, который будет добавлен на сервер. И GET должен вернуть ресурс на сервере.

У вас есть RPC (удаленный вызов процедуры), который не является RESTful - вы хотите что-то сделать на сервере. Поэтому, если вы пытаетесь создать чисто RESTful API, вы должны пересмотреть то, что вы делаете.

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

Если вы это сделаете, я бы порекомендовал PUT или POST, в зависимости от того, является ли RPC idempotent или нет .

В общем, мы говорим, что HTTP PUT сопоставляется с SQL UPDATE и что HTTP POST сопоставляется с SQL INSERT, но это не совсем так. Более чистый способ указать, что HTTP PUT должен быть идемпотентным, и HTTP POST не обязательно. Это означает, что вы можете вызывать один и тот же запрос PUT столько раз, сколько хотите, без побочных эффектов. Как только вы позвонили, как только это станет безобидным, чтобы позвонить ему снова. Но вы не должны повторно вызывать запросы POST, если вы не хотите, - каждый POST снова изменяет данные на сервере.

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

ответил Aaron Greenwald 4 22014vEurope/Moscow11bEurope/MoscowTue, 04 Nov 2014 00:00:27 +0300 2014, 00:00:27
4

Я бы сказал, почему запрос клиента явно должен был сделать вызов, чтобы обновить что-то вроде этого. Похоже, что это должно быть скрытой логикой для более типичной реализации GET (Ie Pull data, но служба делает обновление данных до ее вытягивания) или другим триггером в бэкэнде от клиента.

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

ответил Thomas Stringer 2 72014vEurope/Moscow11bEurope/MoscowSun, 02 Nov 2014 05:25:04 +0300 2014, 05:25:04
4

POST и PUT - это HTTP-глаголы, используемые для отправки объекта на веб-сервер. С помощью PUT представленный объект является (новым) представлением для ресурса в данном URI, который не подходит для того, что вы хотите. POST предназначен для традиционного обработчика формы, где объект является вспомогательными данными для ресурса, так что это победитель. Сущность будет включать в себя команду или действие (например, «action = reload»).

Тем не менее, команда, о которой идет речь, вероятно, не должна отображаться через интерфейс REST. Похоже, необходимость «перезагрузки» возникает из-за того, что данные могут быть изменены через какой-то другой канал (например, файловая система, клиент БД). Кэши должны быть прозрачными. Более того, HTTP-запросы должны быть атомарными, даже принимая сообщения, отправленные по другим каналам. Предоставление команды «перезагрузки» для настроек конфигурации кажется ненужной сложностью; требуя, чтобы он был хрупким. Предоставление «перезагрузки» для очистки после обновления через другой канал является грязным, потому что один канал не содержит весь разговор. Вместо этого рассмотрим один из:

  • обновление полностью через REST
  • отображение команды (ов) другому каналу
  • автоматизация действий

Некоторые из этих параметров могут оказаться нецелесообразными, в зависимости от того, какие существуют другие ограничения.

См. также PUT vs POST в REST ".

ответил outis 2 72014vEurope/Moscow11bEurope/MoscowSun, 02 Nov 2014 06:23:15 +0300 2014, 06:23:15
3

Почему бы не рассматривать действие как ресурс. Поэтому, поскольку вы хотите обновить кеш, вы бы установили новое действие в вашей системе.

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

Общая общесистемная операция /действия /{действие}

Операция, характерная для типа ресурса /действия /{ресурс} /{действие}

Операция, характерная для ресурса /Действий /{ресурс} /{ID} /{действие}

В вашем случае кеш, вероятно, является общесистемным /Действия /reload_cache

ответил Isometriq 29 MaramTue, 29 Mar 2016 00:21:45 +03002016-03-29T00:21:45+03:0012 2016, 00:21:45
-1

Это не случай использования учебника, но если вы хотите быть теоретически совместимым, используйте PUT, который должен обновлять данные. Однако у вас нет полезной нагрузки. Простой GET не был бы настолько плохим в этом случае.

ответил arisalexis 2 72014vEurope/Moscow11bEurope/MoscowSun, 02 Nov 2014 04:52:35 +0300 2014, 04:52:35
-1

HTTP-глаголы не имеют ничего общего с REST.

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

REST - это архитектурный стиль, который в основном связан с тем, как компоненты взаимодействуют друг с другом. Он определяет набор принципов, а не набор протоколов или глаголов.

Вы можете создавать новые ресурсы с помощью глагола DELETE, в то время как это не имеет никакого смысла, и это не является обычным явлением, он все равно может быть полностью RESTFul, если выполняются ограничения.

Что касается вопроса, это не глагол, URL-адрес, формат сообщения, определяющий его REST или нет, а семантику определения API вашей службы и базового протокола. Выполняет ли операция «перезагрузка» любые ограничения REST? Мне кажется, что это не так, поэтому вы можете использовать любой желаемый VERB, он не сделает ваш сервис более или менее RESTful.

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

ответил Yossi 20 MarpmSun, 20 Mar 2016 18:20:51 +03002016-03-20T18:20:51+03:0006 2016, 18:20:51
-2

Я нахожу все ответы очень интересными и проницательными. Однако по первому вопросу есть явный ответ на этот вопрос, который не чувствует себя неудобно: Понимать «перезагрузку» не как действие, а как сигнал. И сигнал - это ресурс. Таким образом, в API стиля REST это будет POST /reloadSignal.

И отправка этого сигнала вызывает соответствующее действие. С точки зрения REST я не думаю, что проблема заключается в том, чтобы не хранить эти сигналы (если это не нужно по соображениям бизнеса).

ответил kartoffelsack 8 Maypm18 2018, 22:18:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132