Zgodnie ze specyfikacją HTTP/1.1 Spec:
Metoda
POST
jest używana do żądania, aby serwer źródłowy zaakceptował encję załączoną w żądaniu jako nową jednostkę podrzędną zasobu identyfikowanego przezRequest-URI
wRequest-Line
.
Innymi słowy, POST
służy do tworzenia.
Metoda
PUT
żąda, aby załączony podmiot został zapisany pod podanymRequest-URI
. JeśliRequest-URI
odnosi się do już istniejącego zasobu, dołączona encja POWINNA być uważana za zmodyfikowaną wersję tej, która znajduje się na serwerze źródłowym. JeśliRequest-URI
nie wskazuje na istniejący zasób, a ten URI może być zdefiniowany jako nowy zasób przez żądającego agenta użytkownika, serwer inicjujący może utworzyć zasób z tym URI."
To znaczy, że PUT
jest używany do tworzenia lub aktualizacji.
Więc, który z nich powinien być używany do tworzenia zasobu? Lub jeden musi obsługiwać oba?
Ogółem:
Zarówno PUT jak i POST mogą być użyte do tworzenia.
Musisz zapytać "do czego wykonujesz akcję?"", aby odróżnić, czego powinieneś użyć. Załóżmy, że projektujesz API do zadawania pytań. Jeśli chcesz użyć POST to zrobisz to do listy pytań. Jeśli chcesz użyć PUT to zrobisz to dla konkretnego pytania.
Obie metody mogą być użyte, więc której z nich powinienem użyć w moim projekcie RESTful:.
Nie musisz obsługiwać zarówno PUT jak i POST.
To, który z nich jest używany, zależy od Ciebie. Ale pamiętaj, aby użyć właściwego w zależności od tego, do jakiego obiektu odwołujesz się w żądaniu.
Kilka uwag:
Przykład:
Napisałem poniższe jako część innej odpowiedzi na SO dotyczącej tego:
POST:.
Służy do modyfikowania i aktualizowania zasobu
POST /questions/
HTTP/1.1 Host: www.example.com/ Zwróć uwagę, że poniższe jest błędem:
POST /questions/
HTTP/1.1 Host: www.example.com/ Jeśli adres URL nie jest jeszcze utworzony, nie powinieneś nie powinieneś używać POST do jego utworzenia podczas określania nazwy. Powinno to skutkować błędem 'resource not found'. ponieważ
<new_question>
nie istnieje jeszcze. Powinieneś PUTować<new_question>
na serwerze. zasób na serwerze jako pierwszy.Możesz jednak zrobić coś takiego jak to, aby utworzyć zasoby używając POST:
POST /questions HTTP/1.1 Host: www.example.com/
Zauważ, że w tym przypadku zasób nazwa nie jest określona, nowe obiekty ścieżka URL zostanie zwrócona do Ciebie.
PUT:
Służy do tworzenia zasobu, lub nadpisać go. Podczas gdy określasz zasobów nowy adres URL.
Dla nowego zasobu:
PUT /questions/
HTTP/1.1 Host: www.example.com/ Aby nadpisać istniejący zasób:
PUT /questions/
HTTP/1.1 Host: www.example.com/
Użyj POST do tworzenia, i PUT do aktualizacji. Tak w każdym razie robi to Ruby on Rails.
PUT /items/1 #=> update
POST /items #=> create
REST jest bardzo wysokopoziomową koncepcją. W rzeczywistości, nawet nie wspomina o HTTP w ogóle!
Jeśli masz wątpliwości, jak zaimplementować REST w HTTP, zawsze możesz zajrzeć do specyfikacji [Atom Publication Protocol (AtomPub)][1]. AtomPub to standard pisania RESTful webservices za pomocą HTTP, który został opracowany przez wielu luminarzy HTTP i REST, z pewnym wkładem Roya Fieldinga, wynalazcy REST i (współ)wynalazcy samego HTTP.
W rzeczywistości, możesz nawet użyć AtomPub bezpośrednio. Choć powstał on w społeczności blogerów, nie jest w żaden sposób ograniczony do blogowania: jest to ogólny protokół do interakcji REST z dowolnymi (zagnieżdżonymi) kolekcjami dowolnych zasobów poprzez HTTP. Jeśli możesz reprezentować swoją aplikację jako zagnieżdżoną kolekcję zasobów, możesz po prostu użyć AtomPub i nie martwić się o to, czy użyć PUT czy POST, jakie kody statusu HTTP zwrócić i wszystkie te szczegóły.
Oto co AtomPub ma do powiedzenia na temat tworzenia zasobów (sekcja 9.2):
Aby dodać członków do kolekcji, klienci wysyłają żądania POST do URI kolekcji.