Зачем использовать методы HTTP PUT и DELETE вместо POST?

 new_story GET     /story/new(.:format)  {:action=>"new", :controller=>"stories"}
edit_story GET     /story/edit(.:format) {:action=>"edit", :controller=>"stories"}
     story GET     /story(.:format)      {:action=>"show", :controller=>"stories"}
           PUT     /story(.:format)      {:action=>"update", :controller=>"stories"}
           DELETE  /story(.:format)      {:action=>"destroy", :controller=>"stories"}
           POST    /story(.:format)      {:action=>"create", :controller=>"stories"}

В веб-разработке, которую я сделал с другими технологиями, я когда-либо использовал только методы GET и POST, но с маршрутами RESTful в Rails, по умолчанию методы PUT и DELETE используются для действий update и destroy. В чем преимущество или необходимость использования PUT и DELETE? Я предполагаю, что эти методы - просто еще один способ сделать POST - но почему бы просто не придерживаться POST?

ОТВЕТЫ

Ответ 1

Преимущество в основном семантическое и может также упростить URL-адреса. Различные методы HTTP сопоставляются с различными действиями:

POST   => create a new object
DELETE => delete an object
PUT    => modify an object
GET    => view an object

Тогда, теоретически, вы можете использовать один и тот же URL-адрес, но взаимодействовать с ним с помощью разных методов; метод, используемый для доступа к ресурсу, определяет фактический тип операции.

На практике, однако, большинство браузеров поддерживают только HTTP GET и POST. Rails использует некоторые "обманки" в HTML-формах, чтобы действовать так, как если бы был отправлен запрос PUT или DELETE, хотя Rails все еще использует GET или POST для этих методов. (Это объясняет, почему вы, возможно, не использовали DELETE или PUT на других платформах.)

Ответ 2

Здесь "methods" раздела спецификации HTTP 1.1; он определяет множество методов, и все они имеют разные преимущества и компромиссы. POST является наиболее гибким, но компромиссы многочисленны: он не кэшируемый (так что остальная часть Интернета не может помочь вам масштабировать), это не безопасно или идемпотент, поэтому клиент не может просто повторно отправить его ошибка, и уже не ясно, что вы пытаетесь выполнить (потому что это так гибко). Я уверен, что есть другие, но этого должно быть достаточно. Учитывая все это, если спецификация HTTP определяет метод, который выполняет именно то, что вы хотите, чтобы ваш запрос выполнял, нет причин отправлять вместо этого POST.

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

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

Ответ 3

Это было бы похоже на вопрос, почему "удалить" файл, если вы можете просто установить его содержимое в нулевые байты, и файловая система будет просто рассматривать это как удаление. HTTP поддерживал глаголы, отличные от GET/POST, но способ, которым SOAP развивался, исказил исходное значение этих глаголов. REST - это более простой подход к основам, который использует глаголы, поскольку они были предназначены вместо того, чтобы изобретать какую-то новую концепцию глагола внутри полезной нагрузки.

Ответ 4

Я просто хотел добавить что-то к принятому ответу, потому что его определение http verbs неверно. Все они имеют спецификацию, которой "следует" следовать, и вы можете создавать/обновлять/удалять с несколькими http verbs на основе спецификаций.

Я собираюсь выделить некоторые важные моменты в RFC 2616 от W3

Я собираюсь начать с PUT потому что, по моему мнению, он наиболее запутан.

  • PUT is used for both create/update PUT updates by completely replacing the resource on the server with the resource sent in the request

Например

Вы делаете этот вызов на мой API

PUT        /api/person
{
     Name: John,
     email: [email protected]
}

мой сервер имеет этот ресурс, живущий на сервере

{
     Name: Jane,
     email: [email protected]
}

Теперь мой существующий ресурс полностью заменен тем, что вы отправили, и это то, что у меня есть на моем сервере.

{
     Name: John,
     email: [email protected]
}

Так что если вы PUT и только отправить по электронной почте в теле

PUT        /api/person
{
     email: [email protected]
}

Мой сервер полностью заменит сущность

{
     Name: Jane,
     email: [email protected]
}

С

{
     email: [email protected]
}

И Имя исчезнет. Частичные обновления предназначены для PATCH но я все равно использую POST для этого.

  • One of the main reasons why we create/update with put is because it is idempotent.

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

пример

Предположим, я PUT файл в api/file если исходный сервер не находит этот файл, он его создаст. Если он найдет файл, он полностью заменит старый файл тем, который я отправил. Это гарантирует, что один файл будет создан и обновлен. Если файла не существует, и вы вызываете PUT 5 раз, первый раз он создает файл, а остальные 4 раза он заменяет файл тем, что вы передаете. Если вы вызываете POST 5 раз, для его создания будет создано 5 файлов.

  • You PUT to that exact URI. If you don't you have to send a 301 (Moved Permanently) to the user and allow then make a choice whether or not to redirect the request. Most times the server you PUT to usually hosts the resource and takes care of updating it

Это основные моменты, когда использовать PUT

Что касается POST

  • You can also create/update and then some...

Как я упоминал выше, есть несколько ключевых отличий.

  • Пост более общий. В каких случаях? некоторые другие примеры включают в себя шлюз к другим протоколам, он может принять ответ и отправить его какому-нибудь обработчику данных в середине того же дня, или он может расширить какую-то функциональность.
  • Сообщение не имеет ограничения "Точный URI или уведомление", например, POST может добавить ресурс в существующую коллекцию и решить, где он хранится.

А как насчет Delete Почему бы мне просто не POST?

Когда вы DELETE, сервер НЕ ДОЛЖЕН отвечать успешно, если вы не удалите ресурс или не переместите его в недоступное место во время отправки ответа.

Почему это важно? Что делать, если вы вызываете DELETE но ресурс должен пройти через "APPROVAL" перед удалением? Если удаление может быть отклонено, вы не можете отправить успешный код ошибки, и если вы действительно следуете основным спецификациям, это сбивает с толку вызывающего. Просто пример, я уверен, что вы можете думать о многих других.

Я только выдвинул на первый план некоторые из основных моментов, когда использовать общие Http verbs