Какой глагол следует использовать для пользовательских действий? - PullRequest
4 голосов
/ 11 июля 2011

Допустим, у нас есть сайт, где у нас есть список товаров.На каждом из этих элементов вы можете запустить несколько разных процессов, которые приведут к некоторому выводу, связанному с данным элементом.Как вы должны разработать наиболее подходящее использование глаголов http?Я хотел бы иметь несколько ссылок на элемент, и каждая ссылка запускает одно из действий, но в моем сценарии это не соответствует получению HTTP-VERB, которое будет использоваться, если я использую ссылки.С другой стороны, я не хочу иметь кнопки, которые все находятся в отдельной форме с различными действиями.

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

Ответы [ 3 ]

4 голосов
/ 12 июля 2011

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

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

POST - самый гибкий глагол,Если процессы, которые вы запускаете, не являются безопасными или идемпотентными (или даже если они есть), вы можете использовать POST, который просто не гарантирует ничего о безопасности или идемпотентности.Существуют следующие недостатки:

  • Если вы используете POST, когда GET более семантически корректен, он менее коммуникативен относительно цели вашего запроса, поскольку POST обычно означает, что вы отправляете полезную нагрузку.
  • Вы просто не смогли воспользоваться преимуществами инфраструктуры кэширования в Интернете, которая делает его настолько масштабируемым.
1 голос
/ 11 июля 2011

В прошлом я использовал POST с аргументами запроса для определения пользовательских действий. Это имело смысл в моем случае использования, потому что у меня было большинство пользовательских действий, необходимых для передачи полезной нагрузки. Поскольку вы не хотите использовать кнопки, вы можете использовать GET с аргументами запроса для указания различных действий, но вы должны быть очень осторожны, чтобы выполняемое вами действие не имело никаких побочных эффектов и являлось идемпотентом. Как отмечено в комментарии @jhericks ниже, в сети есть много вещей, которые предполагают, что GET безопасны и могут повторять GET.

С точки зрения чистого RESTful, это не идеально. Ваши элементы будут иметь определенный URI, а GET на URI будет возвращать представление элементов. Выполнение действий над элементом - это, по сути, изменение состояния представления элемента, и это следует делать с помощью POST (или PUT, в зависимости от того, кого вы спрашиваете, и поддерживает ли ваш веб-сервер PUT). В реальной жизни, однако, использование аргументов запроса легко обойти, и это может иметь смысл для вашего варианта использования.

0 голосов
/ 15 июля 2011

Я не уверен, что полностью понимаю ваш вопрос.

Но вот краткий параграф, который может вам помочь.

REST - это создание умных клиентов и простых серверов. GET, PUT, DELETE представляют основные операции доступа к файлу на самом низком уровне. Вам следует полностью игнорировать все, что может предложить сервер, и перекладывать эту работу на клиентов.

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

Майк Браун

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...