Почему мы используем разные глаголы в Restful API?

Question

Помимо очевидного ответа "Лучшая практика" и "Создает стандарт", есть ли технический аргумент для использования GET, POST, PUT, DELETE и т. Д. Вместо того, чтобы делать все с POST?

Answer 1

В дополнение к созданию Унифицированного интерфейса , различные глаголы имеют разные свойства:

safe (GET, HEAD, OPTIONS,TRACE)

Цель разграничения безопасных и небезопасных методов состоит в том, чтобы автоматизированные процессы поиска (пауки) и оптимизация производительности кэша (предварительная выборка) работали без опасения причинить вред.

идемпотент (PUT, DELETE, GET, HEAD, OPTIONS, TRACE)

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

кешируется : (GET, HEAD, POST)

Методы запроса могут быть определены как «кэшируемые», чтобы указать, что ответы на них разрешено хранить для последующего повторного использования;

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

Answer 2

есть ли технический аргумент для использования GET, POST, PUT, DELETE и т. Д. Вместо того, чтобы делать все с POST?

Да.

В случаеHTTP, одна из важных причин выбрать GET вместо POST - кеширование . RFC 7234 определяет группу семантики кэширования, которая может быть записана в сообщения (особенно в заголовки).

Одной из интересных проблем информатики является аннулирование кэша;в HTTP есть специальная семантика для аннулирования , которая связана с методами:

Кэш ДОЛЖЕН сделать недействительным эффективный URI запроса (раздел 5.5 [RFC7230]), а такжеURI в полях заголовка ответа Location и Content-Location (если они есть), когда в ответ на небезопасный метод запроса принимается код состояния без ошибок.

Другими словами, частьразличие между POST и GET (также HEAD) заключается в том, что универсальные клиенты знают, как аннулировать кэшированные представления ресурсов.Таким образом, я могу использовать сторонний браузер без интерфейса для общения с вашим API, и кэширование «просто работает».

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

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

Answer 3

Эти глаголы являются частью спецификации HTTP, что является основной причиной, по которой мы используем их, когда выполняем REST по HTTP, и в первые дни мы начали делать REST по HTTP, поэтому они стали частью лучшей практики.