Според спецификацията HTTP/1.1:
Методът POST
се използва, за да се поиска от сървъра на произхода да приеме обекта, включен в заявката, като нов подчинен ресурс, идентифициран от Request-URI
в Request-Line
.
С други думи, POST
се използва за създаване.
Методът
PUT
изисква приложената същност да бъде съхранена под предоставенияRequest-URI
. АкоRequest-URI
се отнася до вече съществуващ ресурс, приложената същност ТРЯБВА да се разглежда като модифицирана версия на тази, която се намира на сървъра на произхода. АкоRequest-URI
не препраща към съществуващ ресурс и този URI може да бъде дефиниран като нов ресурс от запитващия потребителски агент, сървърът на произхода може да създаде ресурс с този URI."
Това означава, че PUT
се използва за създаване или актуализиране.
И така, кой от тях трябва да се използва за създаване на ресурс? Или трябва да се поддържат и двете?
Общо:
За създаване на данни могат да се използват както PUT, така и POST.
Трябва да се запитате "за какво извършвате действието?", за да разграничите кое трябва да използвате. Да предположим, че създавате API за задаване на въпроси. Ако искате да използвате POST, тогава ще го направите за списък с въпроси. Ако искате да използвате PUT, ще го направите за конкретен въпрос.
И двете могат да се използват, така че кое от двете трябва да използвам в моя RESTful дизайн:
Не е необходимо да поддържате и PUT, и POST.
Кое от тях ще използвате, зависи от вас. Но просто не забравяйте да използвате правилния в зависимост от това към какъв обект се отнасяте в заявката.
Някои съображения:
Пример:
Написах следното като част от друг отговор в SO по този въпрос:
POST:
Използва се за модифициране и актуализиране на ресурс
POST /questions/
HTTP/1.1 Хост: www.example.com/ Обърнете внимание, че следното е грешка:
POST /questions/
HTTP/1.1 Хост: www.example.com/ Ако URL адресът все още не е създаден, можете не трябва да използвате POST, за да го създадете докато посочвате името. Това трябва да да доведе до грешка 'ресурсът не е намерен' защото
<new_question>
не съществува все още не е създаден. Трябва да ПОСТАВИТЕ<new_question>
ресурс на сървъра.Все пак бихте могли да направите нещо като това, за да създадете ресурс, използвайки POST:
POST /questions HTTP/1.1 Домакин: www.example.com/
Обърнете внимание, че в този случай ресурсът име не е посочено, новите обекти URL път ще ви бъде върнат.
PUT:
Използва се за създаване на ресурс или да го презапишете. Докато посочвате нов URL адрес на ресурса.
За нов ресурс:
PUT /questions/
HTTP/1.1 Хост: www.example.com/ За да презапишете съществуващ ресурс:
PUT /questions/
HTTP/1.1 Хост: www.example.com/
Използвайте POST за създаване и PUT за актуализиране. Поне така го прави Ruby on Rails.
PUT /items/1 #=> update
POST /items #=> create
REST е концепция от много високо ниво. Всъщност в нея изобщо не се споменава HTTP!
Ако имате някакви съмнения относно това как да реализирате REST в HTTP, винаги можете да погледнете спецификацията Atom Publication Protocol (AtomPub). AtomPub е стандарт за писане на RESTful уеб услуги с HTTP, който е разработен от много светила в областта на HTTP и REST, с известно участие на Roy Fielding, изобретател на REST и (съ)изобретател на самия HTTP.
Всъщност може би дори ще можете да използвате AtomPub директно. Въпреки че е създаден от общността на блогърите, той по никакъв начин не се ограничава до тях: това е общ протокол за REST взаимодействие с произволни (вложени) колекции от произволни ресурси чрез HTTP. Ако можете да представите приложението си като вложена колекция от ресурси, тогава можете просто да използвате AtomPub и да не се притеснявате дали да използвате PUT или POST, какви HTTP кодове на състояние да връщате и всички тези подробности.
Ето какво казва AtomPub за създаването на ресурси (раздел 9.2):
За да добавят членове към колекция, клиентите изпращат POST заявки към URI на колекцията.