W sieci można znaleźć twierdzenia, które mówią

• POST powinien być użyty do stworzenia zasobu, a PUT powinien być użyty do modyfikacji jednego
• PUT powinien być użyty do stworzenia zasobu, a POST powinien być użyty do modyfikacji jednego

Ani nie jest całkiem słuszne.

Lepiej wybrać pomiędzy PUT I POST na podstawie idempotencji akcji.

PUT implikuje umieszczenie resource - całkowite zastąpienie tego, co jest dostępne pod danym adresem URL inną rzeczą. Z definicji PUT jest idempotentny. Zrób to tyle razy, ile chcesz, a wynik jest taki sam. x=5 jest idempotentny. Możesz umieścić zasób niezależnie od tego, czy wcześniej istniał, czy nie (np. do utworzenia lub aktualizacji)!

POST aktualizuje zasób, dodaje zasób pomocniczy lub powoduje zmianę. POST nie jest idempotentny, w taki sposób, że {[3] } nie jest idempotentny.

By this argument, PUT służy do tworzenia, gdy znasz adres URL rzeczy, którą utworzysz. POST może być używany do tworzenia, gdy znasz adres URL "fabryki" lub menedżera kategorii rzeczy, które chcesz utworzyć.

Więc:

POST /expense-report

Lub:

PUT  /expense-report/10929

• Na serwerze zdefiniowanym przez Serwer adres URL tworzy zasoby potomne .
• PUT to a URL tworzy/zastępuje zasób w całości pod adresem URL zdefiniowanym przez Klienta.
• łatkado adresu URL aktualizuje Część zasobu pod tym zdefiniowanym przez Klienta adresem URL.

Odpowiednią specyfikacją dla PUT and POST jest RFC 2616 §9.5 ff.

POST tworzy dziecko resource , więc POST To /items tworzy zasoby, które żyją pod zasobem /items. Np. /items/1. Wysłanie tego samego pakietu pocztowego dwa razy stworzy dwa zasoby.

PUT {[7] } służy do tworzenia lub zastępowania zasobu pod adresem URL znanym przez klienta .

Dlatego: PUT jest tylko kandydatem do tworzenia, gdzie klient zna już adres url przed utworzeniem zasobu. Np. /blogs/nigel/entry/when_to_use_post_vs_put jako tytuł jest używany jako klucz zasobów

PUT zastępuje zasób pod znanym adresem url, jeśli już istnieje, więc wysłanie tego samego żądania dwa razy nie ma wpływu. Innymi słowy, wywołania PUT są idempotentne.

RFC czyta tak:

Zasadnicza różnica między żądaniami POST I PUT znajduje odzwierciedlenie w innym znaczeniu Request-URI. URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamknięty podmiot. Ten zasób może być procesem akceptującym dane, bramą do innych protokół, lub oddzielny podmiot akceptujący adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje podmiot załączony do żądania-agent użytkownika wie, jaki URI jest przeznaczony, a serwer nie może próbować zastosować żądania do innego zasobu. Jeśli serwer chce, aby żądanie zostało zastosowane do innego URI,

Uwaga: PUT jest najczęściej używany do aktualizacji zasobów( poprzez zastąpienie ich w całości), ale ostatnio jest ruch w kierunku używanie patcha do aktualizacji istniejących zasobów, jak put określa, że zastępuje on cały zasób. RFC 5789.

Podsumowanie:

Create:

Można wykonać zarówno z PUT, jak i POST w następujący sposób:

PUT

Tworzy nowy zasób z newResourceId jako identyfikatorem, w katalogu / resources URI lub kolekcji .

PUT /resources/<newResourceId> HTTP/1.1 

POST

Tworzy a nowy zasób pod uri /resources, lub zbiór . Zazwyczaj identyfikator jest zwracany przez serwer.

POST /resources HTTP/1.1

Aktualizacja:

Można wykonać tylko w następujący sposób:

PUT

Aktualizuje zasób za pomocą existingResourceId jako identyfikatora, w katalogu / resources URI lub kolekcji .

PUT /resources/<existingResourceId> HTTP/1.1

Wyjaśnienie:

Kiedy mamy do czynienia z REST i URI jako ogólne, masz ogólne na po lewej i specyficzne na po prawej . Na generyki są zwykle nazywane zbiorami, a bardziej specyficzne elementy można nazwać zasobem . Zauważ, że zasób może zawierać zbiór.

Przykłady:

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

Kiedy używasz postu, jesteś zawsze odwołując się do kolekcji , więc kiedy mówisz:

POST /users HTTP/1.1

Dodajesz nowego Użytkownika do użytkownicy kolekcja .

Jeśli spróbujesz czegoś takiego:

POST /users/john HTTP/1.1

To zadziała, ale semantycznie mówisz, że chcesz dodać zasób do john kolekcja pod użytkowników kolekcja .

Gdy używasz PUT, odnosisz się do zasobu lub pojedynczego elementu, ewentualnie wewnątrz kolekcji. Więc kiedy mówisz:

PUT /users/john HTTP/1.1

Mówisz do serwera zaktualizuj lub utwórz, jeśli nie istnieje, john resource under the users kolekcja .

Spec:

Pozwolę sobie podkreślić kilka ważnych części spec:

POST

Metoda POST jest używana do żądania, aby serwer origin zaakceptował encję zawartą w żądaniu jako nowe podrzędne zasobu wskazanego przez Request-URI w Request-Line

Dlatego tworzy nowy zasób na zbiorze .

PUT

Metoda PUT wymaga, aby zamknięty podmiot był przechowywany pod dostarczonym Request-URI. Jeśli Request-URI odnosi się do już istniejącego zasobu, zamknięty obiekt powinien być uważany za zmodyfikowaną wersję tego, który znajduje się na serwerze źródłowym. Jeśli Request-URI nie wskazuje na istniejące zasoby, a że URI jest zdolne być zdefiniowane jako nowy zasób serwer źródłowy może utworzyć zasób z tym URI."

Stąd tworzenie lub aktualizowanie w oparciu o istnienie zasobu .

Odniesienie:

• HTTP / 1.1 Spec
• Wikipedia-reszta
• Uniform Resource Identifiers (URI): Generic Składnia i semantyka

Chciałbym dodać moją "pragmatyczną" radę. Użyj PUT, gdy znasz "id", za pomocą którego można odzyskać zapisany obiekt. Używanie PUT nie będzie działać zbyt dobrze, jeśli potrzebujesz, powiedzmy, identyfikatora wygenerowanego w bazie danych, który ma zostać zwrócony, aby móc w przyszłości wyszukiwać lub aktualizować.

Tak: aby zapisać istniejącego użytkownika lub takiego, w którym klient generuje id i zostało zweryfikowane, że id jest unikalne:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

W przeciwnym razie użyj POST, aby początkowo utworzyć obiekt, A PUT, aby zaktualizować obiekt:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

POST oznacza "utwórz nowego" jak w "Tutaj jest wejście do tworzenia użytkownika, utwórz go dla mnie".

PUT oznacza "Wstaw, zastąp, jeśli już istnieje", jak w "Tutaj są dane dla użytkownika 5".

Piszesz do example.com/users ponieważ nie znasz jeszcze adresu URL użytkownika, chcesz, aby serwer go utworzył.

You PUT to example.com/users/id ponieważ chcesz zastąpić / utworzyć konkretnego użytkownika .

Publikowanie dwa razy z tymi samymi danymi oznacza utworzenie dwóch identycznych użytkowników z różne dokumenty. PUTing dwa razy z tymi samymi danymi tworzy użytkownika pierwszy i aktualizuje go do tego samego stanu za drugim razem (bez zmian). Ponieważ kończysz z tym samym stanem po PUT bez względu na to, ile razy go wykonasz, mówi się, że jest" równie silny " za każdym razem - idempotent. Jest to przydatne do automatycznej ponownej próby żądań. Koniec z "Czy na pewno chcesz ponownie wysłać" po naciśnięciu przycisku Wstecz w przeglądarce.

Ogólną radą jest używanie postu, gdy potrzebujesz serwera do kontroluj generowanie adresów URL swoich zasobów. Użyj umieścić inaczej. Wolę umieścić nad pocztą.

Użyj POST, aby utworzyć, i umieścić do aktualizacji. Tak właśnie robi Ruby on Rails.

PUT    /items/1      #=> update
POST   /items        #=> create

Odpoczynek jest Bardzo pojęciem wysokiego poziomu. W rzeczywistości nawet nie wspomina o HTTP!

Jeśli masz jakiekolwiek wątpliwości, jak zaimplementować REST w HTTP, zawsze możesz rzucić okiem na specyfikację Atom Publication Protocol (AtomPub) . AtomPub jest standardem do pisania RESTful webservices z HTTP, który został opracowany przez wielu luminarzy HTTP i REST, z pewnym wkładem od Roya Fieldinga, wynalazcy REST i (współ) wynalazcy HTTP.

In fact, you może nawet być w stanie używać atompub bezpośrednio. Chociaż wyszedł ze społeczności blogerów, nie jest w żaden sposób ograniczony do blogowania: jest to ogólny protokół do odpoczynku interakcji z arbitralnymi (zagnieżdżonymi) kolekcjami arbitralnych zasobów za pośrednictwem 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 zwracać i wszystkie te szczegóły.

To właśnie AtomPub musi powiedz o tworzeniu zasobów (sekcja 9.2):

Aby dodać członków do kolekcji, klienci wysyłają żądania POST do URI kolekcji.

Decyzja o tym, czy użyć PUT lub POST do utworzenia zasobu na serwerze z HTTP + REST API, zależy od tego, kto jest właścicielem struktury adresu URL. posiadanie przez Klienta wiedzy lub udziału w definiowaniu struktury URL jest niepotrzebnym sprzężeniem podobnym do niepożądanych sprzężeń, które powstały z SOA. Ucieczkowe typy sprzęgieł są powodem, dla którego REST jest tak popularny. Dlatego właściwą metodą jest POST.Istnieją wyjątki od tej zasady i występują, gdy klient chce zachowaj kontrolę nad strukturą lokalizacji wdrażanych zasobów. Jest to rzadkie i prawdopodobnie oznacza, że coś innego jest nie tak.

W tym momencie niektórzy ludzie będą twierdzić, że jeśli RESTful-URL ' s są używane, klient zna adres URL zasobu i dlatego PUT jest akceptowalny. Po tym wszystkim, to jest dlaczego canonical, znormalizowane, Ruby on Rails, Django Urle są ważne, spójrz na API Twitter ... bla bla bla. Ci ludzie muszą zrozumieć, że nie ma czegoś takiego jak Restful-URL i że Roy Fielding sam stwierdza, że :

REST API nie może definiować stałych nazw zasobów ani hierarchii (an oczywiste połączenie klienta i serwera). Serwery muszą mieć wolność aby kontrolować własną przestrzeń nazw. Zamiast tego pozwól serwerom instruować klientów o tym, jak konstruować odpowiednie Uri, np. w HTML formularzy i szablonów URI, poprzez zdefiniowanie tych instrukcji w mediach typy i powiązania. [Awaria tutaj implikuje, że klienci to przyjmując strukturę zasobów ze względu na informacje poza pasmem, takie jak specyficzny dla danej domeny standard, który jest zorientowanym na dane odpowiednikiem RPC ' s functional coupling].

Http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Idea RESTful-URL jest w rzeczywistości naruszeniem REST, ponieważ serwer jest odpowiedzialny za strukturę URL i powinien mieć swobodę decydowania, jak go użyć, aby uniknąć łączenia. Jeśli to cię myli przeczytaj o znaczeniu samodzielnego odkrywania w projektowaniu API.

Korzystanie z POST do tworzenia zasobów wiąże się z rozważaniem projektu, ponieważ POST nie jest idempotentny. oznacza to, że powtarzanie postu kilka razy nie gwarantuje tego samego zachowania za każdym razem. to przeraża ludzi do używania PUT do tworzenia zasobów, gdy nie powinni. wiedzą, że to złe (POST jest dla tworzenia), ale i tak to robią, ponieważ nie wiedzą, jak rozwiązać ten problem. Dotyczy to wykazane w następującej sytuacji:

1. klient publikuje nowy zasób na serwerze.
2. serwer przetwarza żądanie i wysyła odpowiedź.
3. klient nigdy nie otrzymuje odpowiedzi.
4. serwer nie jest świadomy, że Klient nie otrzymał odpowiedzi.
5. klient nie ma adresu URL dla zasobu (dlatego PUT nie jest opcją) i powtarza POST.
POST nie jest idempotentny, a serwer ... ]}

Krok 6 to gdzie ludzie często się mylą co robić. Nie ma jednak powodu, aby tworzyć kludge, aby rozwiązać ten problem. Zamiast tego, HTTP może być użyty w sposób określony w RFC 2616, a serwer odpowiada:

10.4.10 409

Żądanie nie może zostać zakończone z powodu konfliktu z bieżącym stan zasobu. Kod ten jest dozwolony tylko w sytuacjach, gdy oczekuje się, że użytkownik będzie w stanie rozwiązać konflikt i / align = "left" / Prośba. Organ odpowiedzi powinien zawierać wystarczającą ilość

Informacje umożliwiające użytkownikowi rozpoznanie źródła konfliktu. Idealnie, Jednostka odpowiedzi zawierałaby wystarczającą ilość informacji dla użytkownika lub agenta użytkownika, aby rozwiązać problem; jednak może to nie być możliwe i nie jest wymagane.

Konflikty najczęściej występują w odpowiedzi na żądanie PUT. Na przykład, jeśli wersjonowanie było używane, a encja była umieszczana zawarte zmiany w zasobie, które konflikt z tymi dokonanymi przez wcześniejsze (zewnętrzne) żądanie, serwer może skorzystać z odpowiedzi 409 aby wskazać, że nie może wypełnić żądania. W tym przypadku Jednostka odpowiedzi prawdopodobnie zawierałaby listę różnic między obie wersje w formacie określonym przez typ zawartości odpowiedzi.

Odpowiedź z kodem stanu 409 Conflict jest prawidłowym regresem, ponieważ :

• Wykonywanie postu danych, które mają ID pasujące do zasób już w systemie jest " konfliktem z aktualnym stanem zasobu."
• ponieważ ważne jest, aby Klient zrozumiał, że serwer ma zasób i podjął odpowiednie działania. Jest to sytuacja, w której oczekuje się, że użytkownik będzie w stanie rozwiązać konflikt i ponownie przesłać żądanie."
• odpowiedź, która zawiera adres URL zasobu z kolidującym identyfikatorem i odpowiednimi warunkami wstępnymi dla zasobu zapewni " wystarczająco informacje dla użytkownika lub agenta użytkownika, aby rozwiązać problem" co jest idealnym przypadkiem dla RFC 2616.

Aktualizacja oparta na wydaniu RFC 7231 w celu zastąpienia 2616

RFC 7231 jest przeznaczony do zastÄ ... pienia 2616 i w sekcja 4.3.3 opisuje nastÄ ™ pujÄ ... cÄ ... moĹźliwoĹ " Ä ‡ odpowiedzi na POST

Jeśli wynik przetwarzania postu byłby równoznaczny z reprezentacja istniejącego zasobu, serwer źródłowy może przekierowywać agent użytkownika do tego zasób wysyłając odpowiedź 303 (Zobacz inne) z identyfikatorem istniejącego zasobu w polu Lokalizacja. To korzyści płynące z udostępnienia użytkownikowi identyfikatora zasobu i przeniesienie reprezentacji metodą bardziej podatną na współdzielonego buforowania, choć na koszt dodatkowego żądania, jeśli użytkownik agent nie ma jeszcze reprezentacji w pamięci podręcznej.

Teraz może być kuszące, aby po prostu zwrócić 303 w przypadku, gdy POST zostanie powtórzony. Jednak jest odwrotnie. Zwracanie 303 miałoby sens tylko wtedy, gdy wiele żądań utworzenia (tworzenie różnych zasobów) zwróci tę samą zawartość. Przykładem może być "dziękuję za wysłanie wiadomości z prośbą", której klient nie musi ponownie pobierać za każdym razem. RFC 7231 nadal utrzymuje w sekcji 4.2.2, że POST nie powinien być idempotentny i nadal utrzymuje, że POST powinien być używany do tworzenia.

Aby uzyskać więcej informacji na ten temat, przeczytaj ten artykuł .

Oba są używane do transmisji danych między Klientem a serwerem, ale istnieją między nimi subtelne różnice, które są:

Analogia:

• PUT tj. take and put where it was.
• POST jako Wyślij pocztę w post office.

Podoba mi się ta rada, z RFC 2616 definicja PUT :

Zasadnicza różnica między żądaniami POST I PUT znajduje odzwierciedlenie w innym znaczeniu Request-URI. URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamknięty podmiot. Zasób ten może być procesem akceptującym dane, bramą do innego protokołu lub oddzielnym podmiotem akceptującym adnotacje. Natomiast URI we wniosku PUT identyfikuje podmiot zamknięty z żądaniem -- agent użytkownika wie, jaki URI jest przeznaczony i serwer nie może próbować zastosować żądania do jakiegoś innego zasobu.

To łączy się z innymi poradami tutaj, że PUT jest najlepiej stosowany do zasobów, które już mają nazwę, a POST jest dobry do tworzenia nowego obiektu pod istniejącym zasobem(i pozwalając serwerowi nazwać go).

Interpretuję to, a wymagania idempotencji NA PUT oznaczają, że:

• POST jest dobry do tworzenia nowych obiekty w kolekcji (I create nie muszą być idempotentne)
PUT jest dobry do aktualizacji istniejących obiektów (a aktualizacja musi być idempotentna)
• POST może być również używany do nie-idempotentnych aktualizacji istniejących obiektów (zwłaszcza zmiana części obiektu bez określenia całości-jeśli się nad tym zastanowić, utworzenie nowego członka kolekcji jest w rzeczywistości szczególnym przypadkiem tego rodzaju aktualizacji, z perspektywy kolekcji)
• PUT może być również używany do tworzenia wtedy i tylko wtedy, gdy pozwalasz klientowi na nazwanie zasobu. Ale ponieważ klienci REST nie powinni wprowadzać założeń dotyczących struktury adresów URL, jest to mniej zgodne z zamierzonym duchem rzeczy.

W skrócie:

PUT jest idempotentny, gdzie stan zasobu będzie taki sam, jeśli ta sama operacja zostanie wykonana jeden lub wiele razy.

POST jest nie-idempotentny, gdzie stan zasobu może się różnić, jeśli operacja jest wykonywana wielokrotnie w porównaniu z wykonywaniem jednorazowym.

Analogia z zapytaniem do bazy danych

PUT Możesz myśleć podobnie do "UPDATE STUDENT SET address =" abc " gdzie id = "123";

POST możesz wymyślić coś w stylu " INSERT INTO STUDENT (name, address) VALUES ("abc","xyzzz");

Identyfikator ucznia jest generowany automatycznie.

W przypadku PUT, jeśli to samo zapytanie jest wykonywane wiele razy lub jeden raz, stan tabeli studenta pozostaje taki sam.

W przypadku posta, jeśli to samo zapytanie jest wykonywane wiele razy, to w bazie danych powstaje wiele rekordów ucznia, a stan bazy danych zmienia się przy każdym wykonaniu " INSERT" zapytanie.

Notatka: PUT wymaga lokalizacji zasobu (already-resource), na której aktualizacja musi nastąpić, podczas gdy POST tego nie wymaga. Dlatego intuicyjnie POST jest przeznaczony do tworzenia nowego zasobu, podczas gdy PUT jest potrzebny do aktualizacji już istniejącego zasobu.

niektórzy mogą wymyślić, że aktualizacje mogą być wykonywane za pomocą POST. Nie ma twardej reguły, której użyć do aktualizacji lub której użyć do tworzenia. Znowu są to konwencje i intuicyjnie jestem skłaniając się do wyżej wymienionego rozumowania i podążając za nim.

POST jest jak wysłanie listu do skrzynki pocztowej lub wysłanie wiadomości e-mail do kolejki e-mail. PUT jest jak wtedy, gdy umieszczasz obiekt w schowku lub miejscu na półce (ma znany adres).

Z postem piszesz post na adres kolejki lub kolekcji. Z PUT, umieszczasz na adres przedmiotu.

PUT jest idempotentny. Możesz wysłać prośbę 100 razy i nie będzie to miało znaczenia. POST nie jest idempotentny. Jeśli wyślesz żądanie 100 razy, otrzymasz 100 e-maili lub 100 listy w Twojej skrzynce pocztowej.

Ogólna zasada: jeśli znasz IDENTYFIKATOR Lub nazwę elementu, użyj PUT. Jeśli chcesz, aby IDENTYFIKATOR Lub Nazwa przedmiotu zostały przypisane przez Stronę otrzymującą, użyj funkcji POST.

Nowa Odpowiedź (Teraz, gdy lepiej rozumiem odpoczynek):

PUT jest jedynie oświadczeniem o tym, jakie treści usługa powinna od teraz używać do renderowania reprezentacji zasobu zidentyfikowanego przez Klienta; POST jest oświadczeniem o tym, jakie treści usługa powinna od teraz zawierać (być może zduplikowane), ale to od serwera zależy, jak zidentyfikować tę zawartość.

PUT x (if x identyfikuje zasób ): "Zastąp zawartość zasobu identyfikowanego przez x z moją treścią."

PUT x (Jeśli x nie identyfikuje zasobu): "Utwórz nowy zasób zawierający moją zawartość i użyj x, aby go zidentyfikować."

POST x: "przechowuj moją zawartość i podaj mi identyfikator, którego mogę użyć do identyfikacji zasobu (starego lub nowego) zawierającego wspomnianą zawartość (ewentualnie zmieszaną z inną zawartością). Zasób ten powinien być identyczny lub podporządkowany temu, który x identyfikuje.""y's resource is subdicted to x 's resource is zazwyczaj, ale niekoniecznie zaimplementowane przez zrobienie y podstrony x (np. x = /foo i y = /foo/bar) i modyfikowanie reprezentacji(reprezentacji) zasobu x w celu odzwierciedlenia istnienia nowego zasobu, np. z hiperłączem do zasobu y i niektórych metadanych. Tylko ten ostatni jest naprawdę niezbędny do dobrego projektowania, ponieważ adresy URL są nieprzezroczyste w spoczynku - powinieneś używać hypermedia zamiast budowy URL po stronie klienta, aby i tak przejdź przez serwis.

W REST nie ma czegoś takiego jak zasób zawierający "treść". Jako "treść" odwołuję się do danych, które serwis wykorzystuje do spójnego składania oświadczeń. Zazwyczaj składa się z kilku powiązanych wierszy w bazie danych lub pliku (np. pliku obrazu). Do usługi należy przekonwertowanie Treści Użytkownika na coś, z czego usługa może korzystać, np. konwersja JSON payload na instrukcje SQL.

Oryginalna odpowiedź (może być łatwiejsza do Czytaj):

PUT /something (jeśli /something już istnieje): "weź to, co masz w {[11] } i zastąp to tym, co ci daję."

PUT /something (jeśli /something już nie istnieje): "weź to, co ci daję i umieść w /something."

POST /something: "weź to, co ci daję i umieść w dowolnym miejscu pod /something tak długo, jak dasz mi jego adres URL, gdy skończysz."

Ruby on Rails 4.0 użyje metody 'PATCH' zamiast PUT do częściowej aktualizacji.

RFC 5789 mówi o patchu (od 1995 roku):

Nowa metoda jest niezbędna, aby poprawić interoperacyjność i zapobiec błędy. Metoda PUT jest już zdefiniowana w celu nadpisania zasobu z całkowicie nowym ciałem i nie może być ponownie użyty do częściowych zmian. W przeciwnym razie proxy i pamięci podręczne, a nawet klienci i serwery, mogą uzyskać zdezorientowany co do wyniku operacji. POST jest już używany, ale bez szerokiej interoperacyjności (po pierwsze, nie ma standardowego sposobu na discover patch format support). PATCH został wspomniany we wcześniejszym HTTP specyfikacje, ale nie do końca określone.

"Edge Rails: PATCH jest nową podstawową metodą HTTP dla aktualizacji " wyjaśnia to.

Krótka Odpowiedź:

Prosta zasada: użyj POST do tworzenia, użyj PUT do aktualizacji.

Długa Odpowiedź:

POST:

• POST służy do wysyłania danych do serwera.
• przydatne, gdy adres URL zasobu jest unknown

Umieścić:

• PUT służy do przesyłania stanu na Serwer
• przydatne, gdy adres URL zasobu jest znany

Dłuższa Odpowiedź:

Aby to zrozumieć musimy zadać pytanie, dlaczego umieścić było wymagane, jakie problemy postawiono, próbując rozwiązać ten POST nie mógł.

Z punktu widzenia architektury REST nie ma nic, co by się liczyło. Mogliśmy żyć bez PUT, jak również. Ale z punktu widzenia klienta dewelopera uczyniło to jego życie o wiele prostszym.

Przed PUT, klienci nie mogli bezpośrednio znać adresu URL wygenerowanego przez serwer lub czy wszystkie wygenerowane przez niego dane lub czy dane do wysłania na serwer są już zaktualizowane, czy nie. PUT relieve the Wywoływacz tych wszystkich bólów głowy. PUT jest idempotentny, put obsługuje warunki wyścigu, a PUT pozwala klientowi wybrać adres URL.

Ryzykując powtórzenie tego, co już zostało powiedziane, wydaje się ważne, aby pamiętać, że PUT oznacza, że klient kontroluje, czym będzie URL podczas tworzenia zasobu. Więc część wyboru pomiędzy PUT i POST będzie dotyczyć tego, jak bardzo możesz zaufać klientowi w dostarczeniu poprawnego, znormalizowanego adresu URL , który jest spójny z dowolnym schematem URL.

Kiedy nie można w pełni zaufać klientowi, aby słusznie, byłoby bardziej odpowiednie jest użycie POST, aby utworzyć nowy element, a następnie wysłać adres URL z powrotem do Klienta w odpowiedzi.

Najważniejszą kwestią jest wiarygodność . Jeśli wiadomość POST zostanie utracona, stan systemu jest niezdefiniowany. Automatyczne odzyskiwanie jest niemożliwe. W przypadku wiadomości PUT stan jest niezdefiniowany tylko do pierwszej pomyślnej ponownej próby.

Na przykład tworzenie transakcji kartami kredytowymi z postem może nie być dobrym pomysłem.

Jeśli zdarzy ci się, że masz automatycznie wygenerowane URI w swoim zasobie, możesz nadal użyć PUT, przekazując wygenerowany URI (wskazując na pusty zasób) do klienta.

Kilka innych rozważań:

POST unieważnia buforowane kopie całego zasobu (lepsza spójność) Nie można buforować odpowiedzi wysyłanych podczas postów (wymagają treści-lokalizacji i wygaśnięcia).]}
• PUT jest mniej wspierany przez np. Java ME, starsze przeglądarki, firewalle

W bardzo prosty sposób biorę przykład z Facebook timeline.

Przypadek 1: kiedy publikujesz coś na swojej osi czasu, jest to nowy wpis. Tak więc w tym przypadku używają metody POST, ponieważ metoda POST nie jest idempotentna.

Przypadek 2: Jeśli Twój znajomy skomentuje twój post za pierwszym razem, to również utworzy nowy wpis w bazie danych, więc zastosowana metoda POST.

Przypadek 3: Jeśli Twój znajomy edytuje swój komentarz, w tym przypadku miał identyfikator komentarza, więc będzie zaktualizuj istniejący komentarz zamiast tworzyć nowy wpis w bazie danych. Dlatego do tego typu operacji należy użyć metody PUT, ponieważ jest ona idempotentna.*

W jednym wierszu użyj POST, aby dodać nowy wpis do bazy danych i Umieść do zaktualizuj coś w bazie danych.

Wydaje się, że zawsze jest jakieś zamieszanie, kiedy używać HTTP POST w porównaniu z metodą HTTP PUT dla usług REST. Większość programistów będzie próbowała powiązać operacje CRUD bezpośrednio z metodami HTTP. Będę twierdził, że nie jest to poprawne i nie można po prostu skojarzyć pojęcia CRUD z metodami HTTP. Czyli:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

Prawdą jest, że R (etrieve) I d(elete) operacji CRUD mogą być mapowane bezpośrednio do metod HTTP GET I DELETE odpowiednio. Jednak zamieszanie leży w operacjach C (reate) i U (update). W niektórych przypadkach można użyć PUT do tworzenia, podczas gdy w innych przypadkach POST będzie wymagany. Niejednoznaczność polega na definicji metody HTTP PUT kontra metody HTTP POST.

Zgodnie ze specyfikacją HTTP 1.1 metody GET, HEAD, DELETE I PUT muszą być idempotentne, a metoda POST nie jest idempotentna. To znaczy, że operacja jest idempotentna, jeśli może być wykonana na zasobie raz lub wiele razy i zawsze zwracaj ten sam stan tego zasobu. Podczas gdy nie idempotentna operacja może zwrócić zmodyfikowany stan zasobu z jednego żądania do drugiego. W związku z tym, w operacji nie idempotentnej, nie ma gwarancji, że ktoś otrzyma ten sam stan zasobu.

Opierając się na powyższej definicji idempotent, moje podejście do korzystania z metody HTTP PUT w porównaniu do korzystania z metody HTTP POST dla usług REST jest: Użyj metody HTTP PUT, gdy:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

W obu przypadkach operacje te mogą być wykonywane wielokrotnie z tymi samymi wynikami. Oznacza to, że zasób nie zostanie zmieniony przez żądanie operacji więcej niż jeden raz. Stąd prawdziwa operacja idempotentna. Użyj metody HTTP POST, gdy:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

Podsumowanie

Nie koreluje bezpośrednio i nie mapuje operacji CRUD z metodami HTTP dla usług REST. Użycie metody HTTP PUT w porównaniu z metodą HTTP POST powinno opierać się na idempotentnym aspekcie tej operacji. Oznacza to, że jeśli operacja jest idempotentna, to użyj Metoda HTTP PUT. Jeżeli operacja nie jest idempotentna, wtedy należy zastosować metodę HTTP POST.

Serwer origin może utworzyć zasób z tym URI

Więc używasz POST i prawdopodobnie, ale nie jest to konieczne umieścić do tworzenia zasobów. Nie musisz wspierać obu. Dla mnie POST jest w zupełności wystarczający. Jest to więc decyzja projektowa.

Jak wspomniałeś, używasz PUT do tworzenia there is no resource assigned to an IRI, i tak chcesz utworzyć zasób. Na przykład PUT /users/123/password zwykle zastępuje stare hasło nowym, ale można go użyć do Utwórz hasło, jeśli jeszcze nie istnieje (na przykład przez świeżo zarejestrowanych użytkowników lub przywracając zbanowanych użytkowników).

Czytelnicy nowi w tym temacie będą uderzeni niekończącą się dyskusją o tym, co powinieneś robić, i względnym braku lekcji z doświadczenia. To, że odpoczynek jest "preferowany" nad mydłem, jest, jak sądzę, nauką na wysokim poziomie z doświadczenia, ale dobroć, którą musimy się stamtąd rozwijać? Jest 2016 rok. Pracę doktorską Roya obronił w 2000 roku. Co opracowaliśmy? Było fajnie? Czy integracja była łatwa? By wesprzeć? Czy poradzi sobie z rozwojem smartfonów i flaky mobile powiązania?

Według mnie prawdziwe sieci są niewiarygodne. Żąda limitu czasu. Połączenia są resetowane. Sieci przestają działać godzinami lub dniami na raz. Pociągi wjeżdżają do tuneli z użytkownikami mobilnymi na pokładzie. W przypadku każdego żądania (co od czasu do czasu jest potwierdzone w całej tej dyskusji) żądanie może spaść do wody w drodze, lub odpowiedź może spaść do wody w drodze powrotnej. w tych warunkach, wydawanie wniosków PUT, POST i DELETE bezpośrednio przeciwko zasobom merytorycznym ma zawsze wydawało mi się trochę brutalne i naiwne.

HTTP nie robi nic, aby zapewnić niezawodne zakończenie odpowiedzi na żądanie, i to jest w porządku, ponieważ jest to właściwe zadanie aplikacji obsługujących sieć. Rozwijając taką aplikację, możesz przeskakiwać obręcze, aby użyć PUT zamiast POST, a następnie więcej obręczy, aby dać pewien rodzaj błędu na serwerze, jeśli wykryjesz zduplikowane żądania. Z powrotem na klienta, następnie trzeba przejść przez obręcze, aby zinterpretować te błędy, refetch, / align = "left" /

Lub możesz to zrobić : potraktuj swoje niebezpieczne żądania jako efemeryczne zasoby dla pojedynczego użytkownika (nazwijmy je działaniami). Klienci żądają nowego "działania" na materialnym zasobie z pustym postem do zasobu. POST będzie używany tylko w tym celu. Po bezpiecznym uzyskaniu URI świeżo wybitej akcji, klient umieszcza niebezpieczne żądanie na Uri akcji, , a nie na zasobie docelowym . Rozwiązanie akcji i aktualizacja" prawdziwego " zasobu jest prawidłowo zadanie API, i jest tutaj oddzielone od nierzetelnej sieci.

Serwer robi interesy, zwraca odpowiedź i przechowuje ją przeciwko uzgodnionemu Uri akcji . Jeśli coś pójdzie nie tak, klient powtarza żądanie (naturalne zachowanie!jeśli serwer już ją widział, powtarza zapisaną odpowiedź i nie robi nic innego.

Szybko zauważysz podobieństwo z obietnicami: tworzymy i zwracamy symbol zastępczy dla wyniku przed zrobieniem czegokolwiek. Podobnie jak obietnica, akcja może odnieść sukces lub zawieść jeden raz, ale jej wynik może być pobierany wielokrotnie.

Co najlepsze, dajemy możliwość wysyłania i odbierania aplikacji, aby powiązać jednoznacznie zidentyfikowane działanie z wyjątkowością w swoich środowiskach. I możemy zacząć żądać i egzekwować!, odpowiedzialne zachowanie ze strony klientów: powtarzaj swoje żądania tak często, jak chcesz, ale nie Generuj nowych działań, dopóki nie uzyskasz ostatecznego rezultatu z istniejącego.

Jako takie, wiele ciernistych problemów znika. Powtarzające się żądania Wstawienia nie tworzą duplikatów, a my nie tworzymy rzeczywistego zasobu, dopóki nie będziemy w posiadaniu danych. (kolumny bazy danych mogą pozostać nie-nullable). Powtarzające się żądania aktualizacji nie trafią w niezgodne stany i nie nadpiszą kolejnych zmian. Klienci mogą (ponownie)pobrać i bezproblemowo przetworzyć oryginalne potwierdzenie z dowolnego powodu (Klient uległ awarii, odpowiedź zniknęła, itd.).

Kolejne żądania usunięcia mogą zobaczyć i przetworzyć oryginalne potwierdzenie, bez błędu 404. Jeśli sprawy potrwają dłużej niż oczekiwano, możemy odpowiedzieć tymczasowo i mamy miejsce, w którym Klient może sprawdzić ostateczny wynik. Najładniejszą częścią tego wzoru jest jego właściwość Kung-Fu (Panda). Bierzemy słabość, skłonność klientów do powtarzania żądania za każdym razem, gdy nie rozumie odpowiedzi, i zamieniamy ją w siłę :-)

Zanim powiesz mi, że to nie jest odpoczynek, proszę rozważ wiele sposobów, w jaki Zasady odpoczynku są przestrzegane. Klienci nie konstruują adresów URL. API pozostaje wykrywalne, choć z niewielką zmianą w semantyce. Czasowniki HTTP są używane odpowiednio. Jeśli uważasz, że jest to ogromna zmiana do wdrożenia, mogę ci powiedzieć z doświadczenia, że tak nie jest.

Jeśli uważasz, że będziesz miał ogromne ilości danych do przechowywania, porozmawiajmy tomów: typowe potwierdzenie aktualizacji jest ułamkiem kilobajt. HTTP daje obecnie minutę lub dwie, aby odpowiedzieć definitywnie. Nawet jeśli przechowujesz akcje tylko przez tydzień, klienci mają dużą szansę nadrobić zaległości. Jeśli masz bardzo duże wolumeny, możesz potrzebować dedykowanego magazynu wartości klucza zgodnego z kwasem lub rozwiązania w pamięci.

Wyląduję z:

PUT odnosi się do zasobu identyfikowanego przez URI. W takim przypadku aktualizujesz go. Jest to część trzech czasowników odnoszących się do zasobów-delete I get będące dwoma pozostałymi.

POST jest w zasadzie Komunikatem w formie swobodnej, a jego znaczenie jest zdefiniowane jako "poza pasmem". Jeśli wiadomość może być interpretowana jako dodanie zasobu do katalogu, byłoby to OK, ale zasadniczo musisz zrozumieć wiadomość, którą wysyłasz (publikujesz) do wiedzieć, co się stanie z zasobem.

Ponieważ PUT, GET I DELETE odnoszą się do zasobu, są one również z definicji idempotentne.

POST może wykonywać pozostałe trzy funkcje, ale wtedy semantyka żądania zostanie utracona na pośrednikach, takich jak cache i proxy. Dotyczy to również zapewnienia bezpieczeństwa zasobu, ponieważ URI posta niekoniecznie wskazuje zasób, do którego się odnosi (może jednak).

A PUT nie musi być a Utwórz; usługa może wystąpić błąd, jeśli zasób nie jest jeszcze utworzony, ale w przeciwnym razie zaktualizuj go. Lub odwrotnie - może tworzyć zasób, ale nie zezwala na aktualizacje. Jedyną rzeczą wymaganą w PUT jest to, że wskazuje na konkretny zasób, a jego ładunek jest reprezentacją tego zasobu. Pomyślne PUT oznacza (z wyjątkiem zakłóceń), że GET pobierze ten sam zasób.

Edit : jeszcze jedno -- PUT może utworzyć, ale jeśli tak, to ID musi być naturalnym ID -- AKA adres e-mail. W ten sposób, gdy wkładasz dwa razy, drugie Wkładanie jest aktualizacją pierwszego. To sprawia, że idempotent .

Jeśli identyfikator zostanie wygenerowany (np. nowy identyfikator pracownika), to drugi podany z tym samym adresem URL utworzy nowy rekord, który narusza regułę idempotent. W tym przypadku czasownikiem będzie POST, a Komunikatem (nie zasobem) będzie utworzenie zasobu przy użyciu wartości zdefiniowanych w tej wiadomości.

Semantyka ma być inna, ponieważ "PUT", podobnie jak " GET " ma być idempotentne - co oznacza, że możesz dokładnie to samo żądanie PUT wiele razy, a wynik będzie taki, jakbyś wykonał je tylko raz.

Opiszę konwencje, które moim zdaniem są najczęściej używane i najbardziej przydatne:

Kiedy umieścisz zasób pod określonym adresem URL, dzieje się tak, że powinien zostać zapisany pod tym adresem URL lub coś w tym stylu.

Kiedy piszesz do zasób pod określonym adresem URL, często publikujesz powiązaną informację z tym adresem URL. Oznacza to, że zasób pod adresem URL już istnieje.

Na przykład, gdy chcesz utworzyć nowy strumień, możesz umieścić go na jakimś adresie URL. Ale kiedy chcesz wysłać wiadomość do istniejącego strumienia, publikujesz ją na jego adres URL.

Jeśli chodzi o modyfikację właściwości strumienia, możesz to zrobić za pomocą PUT lub POST. Zasadniczo używaj "PUT" tylko wtedy, gdy operacja jest idempotentna - w przeciwnym razie użyj Poczta.

Zauważ jednak, że nie wszystkie nowoczesne przeglądarki obsługują http inne niż GET lub POST.

Przez większość czasu będziesz ich używać w ten sposób:

• dodaj zasób do zbioru
• PUT a resource identified by collection/: id

Na przykład:

• POST / items
• PUT / items / 1234

W obu przypadkach ciało żądania zawiera dane dla zasobu, który ma zostać utworzony lub zaktualizowany. Z nazw tras powinno być oczywiste, że POST nie jest idempotentny (jeśli nazwiesz go 3 razy utworzy 3 obiekty), ale PUT jest idempotentny (jeśli wywołasz GO 3 razy, wynik będzie taki sam). PUT jest często używany do operacji "upsert" (Utwórz lub zaktualizuj), ale zawsze możesz zwrócić błąd 404, jeśli chcesz go tylko zmodyfikować.

Zauważ, że POST "tworzy" nowy element w kolekcji, a PUT "zastępuje" element pod danym adresem URL, ale bardzo powszechną praktyką jest używanie PUT do częściowych modyfikacji, czyli używania go tylko do aktualizacji istniejących zasobów i modyfikowania tylko dołączonych pola w ciele (ignorując pozostałe pola). Jest to technicznie niepoprawne, jeśli chcesz być REST-purystą, PUT powinien zastąpić cały zasób i powinieneś użyć patcha do częściowej aktualizacji. Osobiście nie dbam o to, o ile zachowanie jest jasne i spójne we wszystkich punktach końcowych API.

Pamiętaj, REST jest zbiorem konwencji i wytycznych, aby API było proste. Jeśli skończysz z skomplikowanym obejściem, wystarczy zaznaczyć pole "RESTfull", a następnie pokonasz cel ;)

Chociaż istnieje prawdopodobnie agnostyczny sposób na ich opisanie, wydaje się, że jest to sprzeczne z różnymi stwierdzeniami z odpowiedzi na strony internetowe.

Bądźmy bardzo jasne i bezpośrednie tutaj. Jeśli jesteś programistą. NET pracującym z Web API, fakty są następujące (z Dokumentacji Microsoft API), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations:

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

Jasne, że" możesz "użyć" POST", aby zaktualizować, ale po prostu postępuj zgodnie z konwencje określone dla Ciebie z danej ramy. W moim przypadku jest to.Net / Web API, więc PUT jest do aktualizacji nie ma dyskusji.

Mam nadzieję, że pomoże to wszystkim programistom Microsoftu, którzy czytają wszystkie komentarze z linkami Amazon i Sun / Java website.

Jeśli znasz operacje na bazach danych, istnieją

1. Wybierz
2. Insert
3. Update
4. Usuń
5. Merge (Update if already existing, else insert)

Używam PUT do scalania i aktualizacji jak operacje i używać POST do wstawiania.

W praktyce POST działa dobrze do tworzenia zasobów. Adres URL nowo utworzonego zasobu powinien zostać zwrócony w nagłówku odpowiedzi lokalizacji. PUT powinien być używany do całkowitej aktualizacji zasobu. Proszę zrozumieć, że są to najlepsze praktyki podczas projektowania interfejsu API RESTful. Specyfikacja HTTP jako taka nie ogranicza używania PUT / POST z kilkoma ograniczeniami do tworzenia / aktualizacji zasobów. Spójrz na http://techoctave.com/c7/posts/71-twitter-rest-api-dissected że podsumowuje najlepsze praktyki.

Oto prosta zasada:

PUT to a URL should be used to update or create the resource that can be located at that URL.

POST do adresu URL powinien być użyty do aktualizacji lub utworzenia zasobu, który znajduje się pod innym ("podrzędnym") adresem URL lub nie jest możliwy do zlokalizowania przez HTTP.

POST: Użyj go do tworzenia nowych zasobów. To jak INSERT (polecenie SQL) z auto-incremented ID. W części odpowiedzi zawiera on nowy wygenerowany identyfikator.

POST jest również używany do aktualizacji rekordu.

PUT: Użyj go do stworzenia nowego zasobu, ale tutaj znam klucz tożsamości. To tak jak INSERT (polecenie SQL), gdzie znam z góry klucz tożsamości. W części odpowiedzi nic nie wysyła.

PUT jest również używany do aktualizacji a resource