Поставить пост идемпотентным (REST)

Я не совсем понимаю, как HTTP-глаголы определяются как идемпотентные. Все, что я читал, это GET и PUT-идемпотент. Пост не является идемпотентной. Но вы можете создать REST API, используя POST, который ничего не меняет (например, в базе данных), или создать REST API для PUT, который меняется каждый раз, когда он вызывается.

конечно, это, вероятно, неправильный способ сделать что-то, но если это можно сделать, почему он помечен как идемпотентный (или POST Как нет), когда это зависит от реализации? Я не бросая вызов этой идее, я, вероятно, что-то упускаю, и прошу прояснить мое понимание.

EDIT:

Я думаю, один из способов поставить мой вопрос: Что было бы проблемой, если бы я использовал PUT, чтобы сделать не идемпотентный вызов и сообщение для этого?

8
http idempotent post put rest

3 ответов

вы правы, указывая, что нет ничего, присущего протоколу HTTP, который обеспечивает идемпотентный атрибут методов / глаголов, таких как PUT и DELETE. HTTP, будучи протокол, не сохраняет информацию или статус каждого запроса, который делает пользователь; каждый запрос рассматривается как независимый.

процитировать Википедию на идемпотентный атрибут HTTP-методов (выделено мной):

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

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

вот важная цитата из адресу rfc2616 на HTTP-методах безопасное (выделено мной):

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

в частности, было установлено, что GET и Методы головы не должны иметь значения для принятия решения другие, чем извлечение. Эти методы следует считать "безопасными". Этот позволяет агентам пользователей представлять другие методы, такие как POST, PUT и удалите, особым образом,так, чтобы пользователь был осведомлен из факт, что запрашивается возможно небезопасное действие.

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

обновление: так как указано Юлиан, RFC 2616 был заменен на RFC 7231. вот соответствующий раздел.

поэтому, когда вы публикуете веб-службу как PUT метод, и я отправить запрос, который выглядит так:

PUT /users/<new_id> HTTP/1.1
Host: example.com

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

PUT /users/<existing_id> HTTP/1.1
Host: example.com

Я ожидаю, что соответствующий существующий пользователь будет обновлен. Если я повторяю один и тот же запрос, отправив форму несколько раз, пожалуйста, не открывайте диалоговое окно предупреждения (потому что мне нравится установленное соглашение).

и наоборот, как потребитель веб-службы POST, Я буду ожидать такие запросы, как:

POST /users/<existing_id> HTTP/1.1
Host: example.com

для обновления соответствующего существующего пользователя, в то время как запрос, который выглядит как:

POST /users/<new_id> HTTP/1.1
Host: example.com

вызовет ошибку, потому что URL-адрес еще не существует.

4

надеюсь, что ссылка поможет вам:HTTP метод идемпотентности

будьте осторожны при работе с безопасными методами: если кажущийся безопасным метод, такой как GET, изменит ресурс, возможно, что любые промежуточные клиентские прокси-системы между вами и сервером будут кэшировать этот ответ. Другой клиент, который хочет изменить этот ресурс через тот же URL (например:http://example.org/api/article/1234/delete), не будет вызывать сервер, но возвращает информацию непосредственно из кэша. Небезопасные (и не идемпотентные) методы никогда не будут кэшироваться прокси-серверами промежуточного программного обеспечения.

2

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

1