PUT vs. POST w REST

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:

• Czy nazywasz swoje obiekty URL, które tworzysz jawnie, czy pozwalasz serwerowi zdecydować? Jeśli nadajesz im nazwę, to użyj PUT. Jeśli pozwolisz serwerowi zdecydować, użyj POST.
• PUT jest idempotentny, więc jeśli PUT obiekt dwa razy, to nie ma to żadnego efektu. Jest to fajna właściwość, więc używałbym PUT kiedy to tylko możliwe.
• Możesz aktualizować lub tworzyć zasoby za pomocą PUT z tym samym adresem URL obiektu.
• Z POST możesz mieć 2 żądania przychodzące w tym samym czasie dokonujące modyfikacji adresu URL, i mogą one aktualizować różne części obiektu.

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.