32 Pytanie: PUT vs. POST w REST

pytanie utworzone w Sat, Jul 22, 2017 12:00 AM

Zgodnie ze specyfikacją HTTP /1.1:

  

Metoda POST służy do żądania, aby serwer pochodzenia zaakceptował obiekt zawarty w żądaniu jako nowy podrzędny zasób zidentyfikowany przez Request-URI w Request-Line

Innymi słowy, POST służy do tworzenia .

  

Metoda PUT wymaga, aby obiekt zamknięty był przechowywany pod dostarczonym numerem Request-URI. Jeśli Request-URI odnosi się do już istniejącego zasobu, POWINNA być traktowana jako zmodyfikowana wersja tego zasobu serwer pochodzenia. Jeśli Request-URI nie wskazuje istniejącego zasobu, a identyfikator URI może zostać zdefiniowany jako nowy zasób przez żądającego agenta użytkownika, serwer pochodzenia może utworzyć zasób przy użyciu tego identyfikatora URI. ”

Oznacza to, że PUT służy do utworzenia lub aktualizacji .

Więc, który z nich powinien zostać użyty do utworzenia zasobu? Albo trzeba obsługiwać oba?

    
4996
  1. Pomocne może być użycie definicji w HTTPbis - Roy włożył sporo pracy w ich wyjaśnienie. Zobacz: tools.ietf.org/html/…
    2011-10-23 21: 03: 06Z
  2. Aby sprowadzić komentarz @ MarkNottinghama do najnowszej wersji, oto POST i PUT , jak zdefiniowano w HTTPbis.
    2012-11-18 01: 58: 46Z
  3. Wydaje mi się, że ta debata powstała w wyniku powszechnego upraszczania REST poprzez opisywanie metod HTTP w zakresie operacji CRUD.
    2013-02-14 17: 05: 15Z
  4. Niestety pierwsze odpowiedzi są błędne co do POST. Sprawdź moją odpowiedź, aby uzyskać lepsze wyjaśnienie różnic: stackoverflow.com/a/18243587/2458234
    2013-11-25 05: 21: 37Z
  5. PUT i POST są niebezpiecznymi metodami. Jednak PUT jest idempotentny, podczas gdy POST nie. - Zobacz więcej na: restcookbook.com/HTTP%20Methods/put-vs-post /…
    2014-01-10 20: 26: 49Z
30 odpowiedzi                              30                         

Ogólnie:

Zarówno PUT, jak i POST mogą być używane do tworzenia.

Musisz zapytać „do czego wykonujesz akcję?” rozróżnić, czego powinieneś używać. Załóżmy, że projektujesz API do zadawania pytań. Jeśli chcesz użyć POST, możesz to zrobić na liście pytań. Jeśli chcesz użyć PUT, zrobiłbyś to na konkretne pytanie.

Można użyć wspaniałego obu, więc którego należy użyć w moim projekcie RESTful:

Nie musisz obsługiwać zarówno PUT, jak i POST.

To, co jest używane, zależy od Ciebie. Ale pamiętaj, aby użyć właściwego w zależności od tego, do którego obiektu odwołujesz się w żądaniu.

Kilka uwag:

  • Czy nazywasz obiekty URL, które tworzysz jawnie, czy też pozwalasz serwerowi zdecydować? Jeśli je nazwiesz, użyj PUT. Jeśli pozwolisz serwerowi zdecydować, użyj POST.
  • PUT jest idempotentny, więc jeśli dwa razy PUT obiektu, to nie ma wpływu. Jest to dobra właściwość, więc używałbym PUT, gdy to możliwe.
  • Możesz zaktualizować lub utworzyć zasób z PUT z tym samymadres URL obiektu
  • Dzięki POST możesz mieć 2 żądania przychodzące w tym samym czasie, zmieniając adres URL i mogą aktualizować różne części obiektu.

Przykład:

Napisałem następujące słowa jako część innej odpowiedzi na temat SO dotyczącej tego :

  

POST :

     

Służy do modyfikowania i aktualizowania zasobu

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/
     

Zauważ, że następujący błąd jest następujący:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/
     

Jeśli adres URL nie został jeszcze utworzony, ty   nie powinien używać POST do jego utworzenia   podczas określania nazwy. To powinno   spowoduje błąd „Nie znaleziono zasobu”   ponieważ <new_question> nie istnieje   jeszcze. Powinieneś wpisać <new_question>   Najpierw zasób na serwerze.

     

Można jednak zrobić coś takiego   aby utworzyć zasoby przy użyciu 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 zostałaby ci zwrócona.

     

PUT:

     

Służy do tworzenia zasobu lub   Przepisz to. Podczas gdy określisz   zasoby nowy adres URL.

     

Dla nowego zasobu:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/
     

Aby zastąpić istniejący zasób:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/
    
3941
2017-05-23 11: 55: 13Z
  1. Myślę, że nie można wystarczająco podkreślić faktu, że PUT jest idempotentny: jeśli sieć jest nieudana, a klient nie jest pewien, czy jego żądanie się udało, może po prostu wysłać to drugi (lub 100) czas i jest to gwarantowane przez specyfikację HTTP, która ma dokładnie taki sam efekt jak jednorazowe wysłanie.
    2009-03-10 15: 17: 07Z
  2. @ Jörg W Mittag: Nie jest konieczne. Drugi raz może zwrócić 409 Konflikt lub coś, jeśli żądanie zostało w międzyczasie zmodyfikowane (przez innego użytkownika lub pierwsze samo żądanie, które przeszło).
    2011-11-27 23: 28: 22Z
  3. Jeśli się nie mylę, powinniśmy podkreślić, że PUT jest zdefiniowane , aby być idempotentnym. Nadal musisz napisać swój serwer w taki sposób, aby PUT zachowywał się poprawnie, tak? Być może lepiej powiedzieć „PUT powoduje, że transport zakłada idempotencję, co może wpływać na zachowanie transportu, np. Buforowanie.”
    2011-12-28 02: 05: 20Z
  4. @ JörgWMittag Idempotence catchphrase? Co powiesz na „Wyślij i wyślij i wyślij do mojego przyjaciela, to w końcu nie ma znaczenia.”
    2014-03-03 17: 13: 28Z
  5. Myśli o nich jako: PUT = insert lub update; POST = wstaw. Więc kiedy tworzysz dwa PUT - dostajesz jeden nowy rekord, kiedy robisz dwa POST - dostajesz dwa nowe rekordy.
    2016-08-22 09: 34: 34Z

Możesz znaleźć twierdzenia w sieci, które mówią

Żadne nie jest w porządku.


Lepiej jest wybierać między PUT i POST na podstawie idempotence akcji.

PUT oznacza umieszczenie zasobu - całkowicie zastępując wszystko, 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 ZESTAWIĆ zasób, niezależnie od tego, czy wcześniej istniał, czy nie (np. Utworzyć lub zaktualizować)!

POST aktualizuje zasób, dodaje zasób pomocniczy lub powoduje zmianę. POSTnie jest idempotentny, tak jak x++ nie jest idempotentny.


Przez ten 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 dla kategorii rzeczy, które chcesz utworzyć.

więc:

POST /expense-report

lub:

PUT  /expense-report/10929
    
2075
2013-05-22 05: 56: 05Z
  1. Zgadzam się, niezależnie od tego, gdzie chodzi o idempotence, powinno to przebić wszelkie inne obawy, ponieważ popełnienie tego błędu może spowodować wiele nieoczekiwanych błędów.
    2010-10-26 05: 56: 09Z
  2. Jeśli POST może zaktualizować zasób, jak to nie jest idempotentne? Jeśli zmieniam wiek uczniów za pomocą PUT i robię to 10 razy, wiek uczniów jest taki sam, gdybym to zrobił raz.
    2011-05-06 10: 54: 35Z
  3. @ Schneider, w tym przypadku twój serwer dokłada dodatkowych starań, aby zagwarantować idempotence, ale nie reklamuje go. Przeglądarki nadal ostrzegają użytkownika, jeśli spróbują przeładować takie żądanie POST.
    2012-01-06 10: 53: 35Z
  4. @ Schneider POST może utworzyć zasób pomocniczy; dlatego możesz POST do kolekcji, jak POST /raporty wydatków i utworzyłby tyle podmiotów (raportów wydatków) na serwerze, ile ilości wysłanych żądań, nawet jeśli są one całkowicie podobne . Pomyśl o tym, jak wstawić ten sam wiersz do tabeli DB (/raporty wydatków) z automatycznie zwiększanym kluczem podstawowym. Dane pozostają takie same, klucz (w tym przypadku URI) jest generowany przez serwer i jest inny dla każdej innej wstawki (żądania). Tak więc efekt POST może być idempotentny, ale także może nie. Dlatego POST jest nie idempotentny.
    2012-01-26 17: 32: 20Z
  5. Powiedzmy, że mamy jednostki, które mogą mieć dwie właściwości - name i date. Jeśli mamy podmiot z istniejącym name i date, ale następnie wysyłamy do niego żądania określając tylko name, właściwym zachowaniem PUT byłoby zatarcie date jednostki, podczas gdy POST może zaktualizować tylko określone właściwości, pozostawiając nieokreślone właściwości tak jak przed wniosek został złożony. Czy to brzmi poprawnie /rozsądnie, czy też jest to niewłaściwe użycie PUT (widziałem odniesienia do PATCH , które wydaje się bardziej odpowiednie, ale jeszcze nie istnieje )?
    2013-05-08 18: 28: 14Z
  • POST na adres URL tworzy zasób podrzędny na zdefiniowanym serwerze URL.
  • PUT na adres URL tworzy /zastępuje zasób w całości przy użyciu adresu URL zdefiniowanego klienta.
  • PATCH do adresu URL aktualizuje część zasobu przy zdefiniowanym adresie URL klienta.

Odpowiednia specyfikacja dla PUT i POST to RFC 2616 §9.5 ff.

POST tworzy zasób podrzędny , więc POST na /items tworzy zasoby, które znajdują się pod zasobem /items. Na przykład. /items/1. Dwukrotne wysłanie tego samego pakietu pocztowego spowoduje utworzenie dwóch zasobów.

PUT służy do tworzenia lub zastępowania zasobu przy użyciu adresu URL znanego przez klienta .

Dlatego: PUT jest tylko kandydatem do CREATE, gdzie klient zna adres URL przed utworzeniem zasobu. Na przykład. /blogs/nigel/entry/when_to_use_post_vs_put ponieważ tytuł jest używany jako klucz zasobu

PUT zastępuje zasób w znanym adresie URL, jeśli już istnieje, więc dwukrotne wysłanie tego samego żądania nie ma wpływu. Innymi słowy, połączenia do PUT są idempotentne .

RFC czyta tak:

  

Podstawowa różnica między żądaniami POST i PUT znajduje odzwierciedlenie w innym znaczeniu of URI żądania. Identyfikator URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamkniętą jednostkę. Ten zasób może być procesem akceptującym dane, bramą do innego protokołu lub oddzielną jednostką, która akceptuje adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje jednostkę zamkniętą w żądaniu - agent użytkownika wie, jaki jest adres URI, 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 (zastępując je w całości), ale ostatnio pojawia się ruch w kierunku używania PATCH do aktualizowania istniejących zasobów, ponieważ PUT określa, że ​​zastępuje całość ratunek. RFC 5789.

Aktualizacja 2018 : istnieje przypadek, w którym można uniknąć PUT. Zobacz „REST bez PUT”

  

W technice „REST without PUT” chodzi o to, aby konsumenci byli   zmuszony do opublikowania nowych „nounified” zasobów żądania. Jak ustalono   wcześniej zmiana adresu pocztowego klienta jest POST na nowy   Zasób „ChangeOfAddress”, a nie PUT zasobu „Customer” za pomocą   inna wartość pola adresu pocztowego.

zaczerpnięte z Projektowanie interfejsu API REST - Modelowanie zasobów przez Prakash Subramaniam z Myśli

Wymusza to na interfejsie API unikanie problemów z przejściem od stanu z wieloma klientami aktualizującymi pojedynczy zasób i ładniej pasującymi do źródeł zdarzeń i CQRS. Gdy praca jest wykonywana asynchronicznie, POSTowanie transformacji i oczekiwanie na jej zastosowanie wydaje się właściwe.

    
652
2018-11-26 01: 52: 54Z
  1. Lub z drugiej strony ogrodzenia: PUT, jeśli klient określa adres zasobu wynikowego, POST, jeśli serwer to robi.
    2012-11-28 19: 47: 28Z
  2. Myślę, że ta odpowiedź powinna być edytowana, aby było bardziej jasne, co @DanMan wskazał w bardzo prosty sposób. Najbardziej cenne jest tutaj notatka na końcu, stwierdzająca, że ​​PUT powinien być używany tylko do zastąpienia całego zasobu.
    2013-11-26 22: 37: 51Z
  3. PATCH nie jest realistyczną opcją przez co najmniej kilka lat, ale zgadzam się z ideologią.
    2014-10-03 17: 33: 08Z
  4. Próbuję zrozumieć, ale użycie PUT do stworzenia czegoś miałoby sens tylko wtedy, gdyby klient wiedział na pewno, że zasób jeszcze nie istnieje, prawda? Podążając za przykładem bloga, powiedzmy, że stworzyłeś setki postów na blogu w ciągu kilku lat, a potem przypadkowo wybierzesz ten sam tytuł, co dwa lata temu. Teraz odszedłeś i zastąpiłeś ten post, który nie był przeznaczony. Tak więc użycie PUT do stworzenia wymagałoby od klienta śledzenia tego, co zostało zrobione, a co nie, a także może prowadzić do wypadków i niezamierzonych skutków ubocznych, a także mieć trasy, które wykonują dwie zupełnie różne rzeczy?
    2015-01-30 09: 01: 22Z
  5. Masz rację. WPROWADZENIE wpisu na blogu w tym samym adresie URL, co istniejący, spowodowałoby aktualizację tego istniejącego posta (chociaż można oczywiście sprawdzić najpierw GET). Wskazuje to, dlaczego złym pomysłem byłoby używanie tytułu jako adresu URL. Działałoby to jednak wszędzie tam, gdzie w danych był naturalny klucz ... co w moim doświadczeniu jest rzadkie. Lub jeśli użyłeś identyfikatorów GUI
    2015-02-03 05: 20: 12Z

Podsumowanie:

Utwórz:

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

  

PUT

     

Tworzy THE nowy zasób z newResourceId jako identyfikatorem, pod identyfikatorem URI zasobów / lub kolekcją .

PUT /resources/<newResourceId> HTTP/1.1 
     

POST

     

Tworzy nowy zasób w ramach identyfikatora URI zasobów / lub . Zwykle identyfikator jest zwracany przez serwer.

POST /resources HTTP/1.1

Aktualizacja:

Czy można tylko wykonać PUT w następujący sposób:

  

PUT

     

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

PUT /resources/<existingResourceId> HTTP/1.1

Wyjaśnienie:

Jeśli chodzi o REST i URI jako ogólne, masz ogólny w lewym i określonym w prawym . Ogólne są zwykle nazywane kolekcjami , a bardziej specyficzne elementy można nazwać zasobami . Pamiętaj, że zasób może zawierać kolekcję .

  

Przykłady:

     

< - ogólne - specyficzne - >

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

Gdy używasz POST, zawsze odwołujesz się do kolekcji , więc kiedy mówisz:

POST /users HTTP/1.1

publikujesz nowego użytkownika w kolekcji użytkowników .

Jeśli przejdziesz dalej i spróbujesz czegoś takiego:

POST /users/john HTTP/1.1

będzie działać, ale semantycznie mówisz, że chcesz dodać zasób do john kolekcji pod użytkownikami kolekcja .

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

PUT /users/john HTTP/1.1

powiadamiasz serwer o aktualizacji lub utwórz, jeśli nie istnieje, zasób john pod użytkownikami kolekcja .

Spec:

Pozwólcie, że podkreślę niektóre ważne części specyfikacji:

POST

  

Metoda POST służy do zażądania od serwera źródłowego zaakceptowania encji zawartej w żądaniu jako nowego podrzędnego zasobu zidentyfikowanego przez URI żądania w linii żądania

Stąd tworzy nowy zasób w kolekcji .

PUT

  

Metoda PUT wymaga, aby załączony podmiot był przechowywany w dostarczonym URI żądania. Jeśli identyfikator URI żądania odnosi się do już istniejącego zasobu , dołączony obiekt POWINIEN być uważany za zmodyfikowaną wersję tego, który znajduje się na serwerze pochodzenia. Jeśli identyfikator żądania URI nie wskazuje istniejącego zasobu , a identyfikator URI jest zdolny do zdefiniowania jako nowy zasób przez żądającego agenta użytkownika, serwer pochodzenia może utworzyć zasób z tym URI. ”

Stwórz zatem lub zaktualizuj na podstawie istnienia zasobu .

Odniesienie:

192
2016-02-09 18: 25: 43Z
  1. Ten post był dla mnie pomocny w zrozumieniu, że POST dodaje „coś” jako dziecko do podanej kolekcji (URI), podczas gdy PUT wyraźnie definiuje „coś” w podana lokalizacja URI.
    2013-11-23 16: 33: 19Z
  2. Myślę, że to najlepsza odpowiedź: żaden z tych "POSTów nie może aktualizować nonsensów zasobów". Podoba mi się twoje stwierdzenie: „Aktualizacja może być wykonana tylko za pomocą PUT”.
    2015-05-28 13: 44: 40Z
  3. Nie, PUT nie jest przeznaczony do aktualizacji ani tworzenia. To jest do wymiany. Zauważ, że nie możesz niczego zastąpić czymś w celu stworzenia.
    2015-06-08 08: 07: 28Z
  4. @ 7hi4g0 PUT służy do aktualizacji z pełnym zastąpieniem, innymi słowy, zastępuje. Nic nie zastępujesz czymś lub czymś zupełnie nowym. PP nie jest do tego zdolnyg niewielka zmiana (chyba, że ​​klient wprowadzi tę drobną zmianę i zapewni całą nową wersję, nawet to, co pozostanie bez zmian). W przypadku modyfikacji częściowej PATCH jest metodą z wyboru.
    2015-06-08 12: 57: 21Z
  5. @ thecoshman Mógłbyś, ale nie byłoby to zbyt jasne, że tworzenie jest tam również opisane. W tym przypadku lepiej być wyraźnym.
    2015-06-09 20: 21: 12Z

Chciałbym dodać moją „pragmatyczną” radę. Użyj PUT, gdy znasz „id”, o który można zapisać zapisywany obiekt. Używanie PUT nie będzie działało zbyt dobrze, jeśli potrzebujesz, na przykład, wygenerowanego identyfikatora bazy danych, który ma zostać zwrócony w celu późniejszego wyszukiwania lub aktualizacji.

Więc: Aby zapisać istniejącego użytkownika lub taki, w którym klient generuje identyfikator i zweryfikowano, że identyfikator jest unikalny:

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
    
170
2011-05-25 03: 43: 05Z
  1. Właściwie powinno to być POST /users. (Należy pamiętać, że /users jest liczbą mnogą.) Ma to wpływ na utworzenie nowego użytkownika i uczynienie go zasobem podrzędnym kolekcji /users.
    2014-12-16 13: 54: 53Z
  2. @ DavidRR, aby być uczciwym, jak obsługiwać grupy to kolejna debata. GET /users ma sens, czyta tak, jak chcesz, ale byłbym w porządku z GET /user/<id> lub POST /user (z ładunkiem dla nowego użytkownika), ponieważ czyta poprawnie „pobierz mnie 5” jest nieparzysty, ale „pobierz mnie 5” to więcej naturalny. Prawdopodobnie jednak nadal spadłbym na stronę pluralizacji :)
    2015-06-08 07: 57: 14Z

POST oznacza „stwórz nowy” jak w „Oto dane wejściowe do utworzenia użytkownika, stwórz go dla mnie”.

PUT oznacza „wstaw, zamień jeśli już istnieje” jak w „Oto dane dla użytkownika 5”.

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

PUT trafiasz do example.com/users/id, ponieważ chcesz zastąpić /utworzyć konkretnego użytkownika.

Dwukrotne testowanie POST przy użyciu tych samych danych oznacza utworzenie dwóch identycznych użytkowników o różnych identyfikatorach. Dwukrotne wprowadzenie tych samych danych powoduje, że użytkownik staje się pierwszym i aktualizuje go do tego samego stanu po raz drugi (bez zmian). Ponieważ po PUT kończysz z tym samym stanem, niezależnie od tego, ile razy go wykonasz, mówi się, że za każdym razem jest „równie silny” - idempotentny. Jest to przydatne do automatycznego ponawiania żądań. Nigdy więcej „czy na pewno chcesz wysłać ponownie” po naciśnięciu przycisku Wstecz w przeglądarce.

Ogólną radą jest używanie POST, gdy serwer musi kontrolować generowanie adresów URL zasobów. Użyj PUT inaczej. Wolisz PUT niż POST.

    
163
2017-04-23 18: 13: 45Z
  1. Sloppiness może spowodować, że będzie powszechnie nauczane, że są tylko dwa czasowniki, których potrzebujesz: GET i POST. GET, aby uzyskać, POST do zmiany. Nawet PUT i DELETE były wykonywane przy użyciu POST. Pytanie o to, co naprawdę oznacza PUT 25 lat później, może na początku źle się nauczyliśmy. Popularność REST doprowadziła ludzi do powrotu do podstaw, w których musimy teraz oduczyć się złych błędów. POST był nadużywany, a teraz powszechnie nauczany nieprawidłowo. Najlepsza część: „POSTowanie dwa razy za pomocą tych samych danych oznacza utworzenie dwóch identycznych [zasobów]”. Świetny punkt!
    2014-09-01 19: 36: 14Z
  2. Jak można użyć PUT do utworzenia rekordu według ID, jak w przykładzie user 5, jeśli jeszcze nie istnieje? Nie masz na myśli update, replace if already exists? lub coś
    2014-11-28 12: 44: 13Z
  3. @ Coulton: Miałem na myśli to, co napisałem. Wstawiasz użytkownika 5, jeśli PUT do /users /5 i # 5 jeszcze nie istnieje.
    2014-11-28 15: 46: 33Z
  4. @ Coulton: I PUT można również użyć do zastąpienia wartości istniejącego zasobu w całości.
    2014-12-16 14: 02: 34Z
  5. "Preferuj PUT ponad POST" ... staraj się to uzasadnić?
    2015-06-08 08: 04: 31Z

Użyj POST do utworzenia i PUT do aktualizacji. Tak właśnie robi Ruby on Rails.

PUT    /items/1      #=> update
POST   /items        #=> create
    
121
2017-09-16 20: 17: 08Z
  1. POST /items dodaje nowy element do już zdefiniowanego zasobu („element”). Nie odpowiada, jak mówi odpowiedź, „tworzeniu grupy”. Nie rozumiem, dlaczego ma 12 głosów.
    2012-06-21 05: 26: 07Z
  2. To jest uczciwa wskazówka, ale nadmierne uproszczenie. Jak wspominają inne odpowiedzi, obie metody mogą być używane zarówno do tworzenia, jak i aktualizacji.
    2013-03-07 15: 55: 49Z
  3. Zgadzam się z odpowiedzią z niewielką modyfikacją. Użyj POST do utworzenia i PUT, aby całkowicie zaktualizować zasób. W przypadku częściowych aktualizacji możemy użyć PUT lub PATCH. Powiedzmy, że chcemy zaktualizować status grupy. Możemy użyć PUT /grup /1 /status ze statusem to ładunek żądania lub PATCH /grupy /1 ze szczegółami dotyczącymi akcji w ładunku
    2014-10-06 06: 26: 04Z
  4. Należy również wyjaśnić, że PUT /items/42 jest również ważne dla tworzenia zasobu, , ale tylko wtedy, gdy klient ma przywilej nazywanie zasobu . (Czy Railsy pozwalają klientowi na to uprawnienie do nadawania nazw?)
    2014-12-16 14: 10: 00Z
  5. replace is better word for PUT patch jest do aktualizacji
    2016-01-20 06: 59: 37Z

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

 Wpisz opis obrazu tutaj>> </a> </p>

<p> Analogia: </p>

<ul>
<li> PUT, czyli weź i <strong> umieść </strong> tam, gdzie to było. </li>
<li> POST jako wysyłanie poczty w biurze <strong> post </strong>. </li>
</ul>
<p> <a href= wprowadź opis obrazu tutaj>> </a> </p>

<p> Analogia mediów społecznościowych /sieciowych: </p>

<ul>
<li>
<strong> Opublikuj </strong> w mediach społecznościowych: po opublikowaniu wiadomości tworzy nowy post. </li>
<li>
<strong> Umieść </strong> (np. edytuj) dla wiadomości, którą już wysłaliśmy. </li>
</ul> </div>
<div class = 96

2019-03-29 02: 54: 21Z
  1. Podsumowując: POST dla insertów, PUT dla aktualizacji
    2015-09-22 12: 31: 19Z
  2. @ MobileMon Nie, metody REST nie są CRUD.
    2016-01-08 19: 06: 38Z
  3. Powiedziałbym, że PUT for UPSERTS
    2018-11-26 11: 45: 16Z

REST to bardzo koncepcja wysokiego poziomu. W rzeczywistości nawet nie wspomina o HTTP!

Jeśli masz jakiekolwiek wątpliwości dotyczące implementacji REST w HTTP, zawsze możesz spojrzeć na Specyfikacja Atom Publication Protocol (AtomPub) . AtomPub jest standardem do pisania RESTful webservices z HTTP, który został opracowany przez wiele luminarzy HTTP i REST, z pewnym wkładem Roy'a Fieldinga, wynalazcy REST i (współ) wynalazcy samego HTTP.

W rzeczywistości możesz nawet korzystać z AtomPub bezpośrednio. Choć pochodzi ze społeczności blogów, w żaden sposób nie ogranicza się do blogowania: jest to ogólny protokół RESTfully współdziałający z dowolnymi (zagnieżdżonymi) kolekcjami dowolnych zasobów za pośrednictwem protokołu 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 lub POST, jakie kody stanu HTTP powrócić i wszystkie te szczegóły.

To jest to, 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.

    
65
2018-07-27 14: 37: 27Z
  1. Nie ma nic złego w zezwalaniu PUT na tworzenie zasobów. Pamiętaj tylko, że oznacza to, że klient podaje adres URL.
    2010-04-07 07: 47: 32Z
  2. Coś jest nie tak z zezwoleniem PUT na tworzenie zasobów: klient podaje adres URL. To zadanie serwera!
    2013-10-29 17: 33: 01Z
  3. @ Joshcodes Tworzenie identyfikatorów klienta nie zawsze jest zadaniem serwera. Coraz częściej widziałem projekty, które pozwalały klientom generować pewien rodzaj UUID jako identyfikator zasobu. Ten projekt nadaje się szczególnie do zwiększenia skali.
    2017-02-05 18: 26: 16Z
  4. @ JustinOhms Zgadzam się z twoim punktem na temat identyfikatorów wygenerowanych przez klienta (uwaga: wszystkie systemy zaprojektowane przeze mnie od około 2008 roku wymagają od klienta utworzenia identyfikatora jako UUID /Guid ). Nie oznacza to, że klient powinien podać adres URL.
    2017-02-06 18: 24: 26Z
  5. Tak, jeśli zasób już istnieje, użyj PUT. Jednak prawie we wszystkich przypadkach zasoby powinny być tworzone za pomocą POST, a klient nie powinien podawać adresu URL. Roy Fielding zgadza się z tym stwierdzeniem FWIW: roy.gbiv. com /untangled /2008 /rest-apis-must-be-hypertext sterowany
    2017-02-07 01: 26: 05Z

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

W tym momencie niektórzy ludzie twierdzą, że jeśli URL RESTful jest używany, klient zna adres URL zasobu i dlatego PUT jest dopuszczalne. W końcu to dlatego kanoniczne, znormalizowane, Ruby on Rails, adresy URL Django są ważne, spójrz na Twitter API… bla bla bla. Ci ludzie muszą zrozumieć nie ma czegoś takiego jak Restful-URL i Roy Fielding sam stwierdza, że ​​:

  

Interfejs API REST nie może definiować stałych nazw zasobów ani hierarchii (an   obvsprzężenie klienta i serwera). Serwery muszą mieć wolność   kontrolować własną przestrzeń nazw. Zamiast tego zezwól serwerom na instruowanie   klientów na temat konstruowania odpowiednich URI, takich jak w HTML   formularze i szablony URI, definiując te instrukcje w mediach   typy i powiązania relacji. [Niepowodzenie oznacza, że ​​klienci są   przyjmując strukturę zasobów z powodu informacji poza pasmem, takich jak   standard specyficzny dla domeny, który jest odpowiednikiem zorientowanym na dane   Funkcjonalne połączenie RPC].

     

http://roy.gbiv.com/untangled /2008 /rest-apis-must-be-hypertext sterowany

Pomysł RESTful-URL jest w rzeczywistości naruszeniem REST, ponieważ serwer jest odpowiedzialny za strukturę adresu URL i powinien mieć swobodę decydowania, jak go użyć, aby uniknąć sprzężenia. Jeśli to wprowadzi w błąd, przeczytaj o znaczeniu odkrywania samego siebie w projektowaniu API.

Używanie POST do tworzenia zasobów przychodzi z uwzględnieniem projektu, ponieważ POST nie jest idempotentny. Oznacza to, że wielokrotne powtarzanie POST nie gwarantuje za każdym razem takiego samego zachowania. To przeraża ludzi do używania PUT do tworzenia zasobów, kiedy nie powinni. Wiedzą, że to źle (POST to CREATE), ale i tak to robią, ponieważ nie wiedzą, jak rozwiązać ten problem. Ta obawa została wykazana w następującej sytuacji:

  1. Klient POST nowego zasobu na serwer.
  2. Serwer przetwarza żądanie i wysyła odpowiedź.
  3. Klient nigdy nie otrzyma 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 test POST.
  6. POST nie jest idempotentny, a serwer…

Krok 6 to miejsce, w którym ludzie często mylą się co robić. Nie ma jednak powodu, aby stworzyć problem do rozwiązania tego problemu. Zamiast tego można użyć HTTP, jak określono w RFC 7231 ma zastąpić 2616 i Rozdział 4.3.3 opisuje następującą możliwą odpowiedź dla POST

  

Jeśli wynik przetwarzania POST byłby równoważny z a   reprezentacja istniejącego zasobu, serwera pochodzenia MOŻE przekierować   agent użytkownika do tego zasobu, wysyłając odpowiedź 303 (Zobacz inne)   z identyfikatorem istniejącego zasobu w polu Lokalizacja. To   ma zalety dostarczania agentowi użytkownika identyfikatora zasobu   i przekazywanie reprezentacji za pomocą bardziej odpowiedniej metody   wspólny okching, ale kosztem dodatkowego żądania, jeśli użytkownik   agent nie ma jeszcze buforowanej reprezentacji.

Teraz może być kuszące po prostu zwrócenie 303 w przypadku powtórzenia testu POST. Jednak jest odwrotnie. Zwrócenie 303 miałoby sens tylko wtedy, gdy wiele żądań tworzenia (tworzących różne zasoby) zwraca tę samą treść. Przykładem może być „dziękuję za przesłanie wiadomości z prośbą”, że klient nie musi ponownie pobierać za każdym razem. RFC 7231 nadal utrzymuje w sekcji 4.2.2, że POST nie ma być idempotentny i nadal utrzymuje, że POST powinien być używany do tworzenia.

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

    
59
2017-10-21 12: 39: 27Z
  1. Czy odpowiedź na konflikt 409 byłaby odpowiednim kodem dla czegoś takiego jak próba utworzenia nowego konta z nazwą użytkownika, która już istnieje? Używam 409 specjalnie do konfliktów wersjonowania, ale po przeczytaniu odpowiedzi zastanawiam się, czy nie powinna być używana do jakichkolwiek „duplikatów” żądań.
    2014-07-09 04: 43: 34Z
  2. @ EricB. Tak, w sytuacji, którą opisujesz „z powodu konfliktu z bieżącym stanem zasobu”, operacja kończy się niepowodzeniem. Ponadto rozsądnie jest oczekiwać, że użytkownik może rozwiązać konflikt, a treść wiadomości musi jedynie poinformować użytkownika, że ​​nazwa użytkownika już istnieje.
    2014-07-10 13: 25: 23Z
  3. @ Joshcodes czy możesz powiedzieć więcej o procesie rozwiązywania konfliktów? W takim przypadku, jeśli nazwa użytkownika już istnieje, klient oczekuje, że poprosi użytkownika końcowego o inną nazwę użytkownika? Co jeśli klient rzeczywiście próbuje użyć POST do zmiany nazwy użytkownika? Czy żądania PUT nadal powinny być używane do aktualizacji parametrów, podczas gdy POST jest używany do tworzenia obiektów, niezależnie od tego, czy jest to jeden czy kilka? Dzięki.
    2015-01-22 22: 41: 13Z
  4. @ BFar2 jeśli nazwa użytkownika już istnieje, klient powinien zapytać użytkownika. Aby zmienić nazwę użytkownika, zakładając, że nazwa użytkownika jest częścią już utworzonego zasobu, który wymaga modyfikacji, PUT byłby używany, ponieważ masz rację, POST jest używany do tworzenia, zawsze i PUT do aktualizacji.
    2015-01-23 01: 09: 44Z
  5. wyjaśnianie rzeczy za pomocą krótkiego i skutecznego języka jest również pożądaną umiejętnością
    2015-08-24 16: 27: 49Z

Podoba mi się ta rada z definicji PUT RFC 2616:

  

Podstawowa różnica między żądaniami POST i PUT znajduje odzwierciedlenie w innym znaczeniu URI żądania. Identyfikator URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamkniętą jednostkę. Ten zasób może być procesem akceptującym dane, bramą do innego protokołu lub oddzielną jednostką, która akceptuje adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje jednostkę zamkniętą w żądaniu - agent użytkownika wie, co jest przeznaczone przez URI, a serwer NIE MOŻE próbować zastosować żądania do innego zasobu.

To wymyka się innym wskazówkom tutaj, że PUT jest najlepiej stosowany do zasobów, które już mają nazwę, a POST jest dobry do tworzenia nowego obiektu w istniejącym zasobie (i pozwalania serwerowi nazwać go).

Zinterpretowałem to i wymagania idempotency na PUT, co oznacza, że:

  • POST jest dobry do tworzenia nowych obiektów w ramach kolekcji (i tworzenie nie musi być idempotentne)
  • PUT jest dobry do aktualizowania istniejących obiektów (i aktualizacja musi być idempotentna)
  • POST może być również użyty dla nieidempotentnych aktualizacji istniejących obiektów (szczególnie, zmiana części obiektu bez określenia całej rzeczy - jeśli o tym pomyślisz, utworzenie nowego członka kolekcji jest w rzeczywistości specjalnym przypadkiem ten rodzaj aktualizacji z perspektywy kolekcjiive)
  • PUT może być również używany do tworzenia wtedy i tylko wtedy, gdy pozwolisz klientowi nazwać zasób. Ale ponieważ klienci REST nie powinni przyjmować założeń dotyczących struktury adresów URL, jest to mniej w zamierzonym duchu rzeczy.
52
2012-01-11 17: 18: 54Z
  1. "POST może być również użyty dla nieidempotentnych aktualizacji istniejących obiektów (szczególnie, zmiana części obiektu bez określenia całej rzeczy". To właśnie jest PATCH
    2012-05-04 22: 11: 24Z

W skrócie:

PUT jest idempotentny, gdy stan zasobów będzie taki sam, jeśli ta sama operacja zostanie wykonana raz lub wiele razy.

POST nie jest idempotentny, gdy stan zasobów może się różnić, jeśli operacja jest wykonywana wiele razy w porównaniu z wykonaniem pojedynczego razu.

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 rodzaju „WSTAW DO STUDENTA (nazwa, adres) WARTOŚCI („ abc ”,„ xyzzz ”);

Identyfikator ucznia jest generowany automatycznie.

W przypadku PUT, jeśli to samo zapytanie jest wykonywane wielokrotnie lub raz, stan tabeli STUDENT pozostaje taki sam.

W przypadku POST, jeśli to samo zapytanie jest wykonywane wielokrotnie, wiele rekordów Uczniów jest tworzonych w bazie danych, a stan bazy danych zmienia się przy każdym wykonaniu zapytania „INSERT”.

UWAGA: PUT potrzebuje lokalizacji zasobów (już zasobu), w której musi nastąpić aktualizacja, 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 utworzenia. Ponownie są to konwencje i intuicyjnie jestem skłonny do wyżej wspomnianego rozumowania i podążam za tym.

    
46
2017-10-21 12: 46: 45Z
  1. dla PUT jest podobny do zapytania INSERT lub UPDATE
    2016-08-22 09: 25: 53Z
  2. faktycznie PUT Możesz myśleć podobnie do "UPDATE STUDENT SET address =" abc "gdzie id =" 123 "; byłoby instrukcją PATCH." UPDATE STUDENT SET address = "abc", name = "newname" where id = "123" byłoby poprawną analogią do PUT
    2017-04-12 13: 24: 36Z
  3. Put może być również użyty dla INSERT. Na przykład, jeśli serwer wykrył, że próbowałeś przesłać ten sam plik wiele razy, spowodowałoby to, że twoje żądanie byłoby idempotentne. (Nie są przesyłane żadne nowe pliki).
    2018-08-20 22: 46: 20Z

Test POST przypomina wysyłanie listu do skrzynki pocztowej lub wysyłanie wiadomości e-mail do kolejki e-mail. PP to tak, jakbyś umieścił przedmiot w schowku lub na półce (ma znany adres).

W przypadku POST publikujesz na adres KOLEJKI lub KOLEKCJI. Z PUT umieszczasz adres ITEM.

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

Ogólna zasada: jeśli znasz identyfikator lub nazwę przedmiotu, użyj PUT. Jeśli chcesz, aby identyfikator lub nazwa elementu, który ma zostać przypisany przez odbiorcę, użyj POST.

POST a PUT

    
42
2013-07-10 19: 52: 13Z
  1. Nie, PUT oznacza, że ​​znasz adres URL. Jeśli znasz tylko identyfikator, POST z tym identyfikatorem, aby uzyskać adres URL.
    2013-10-29 17: 35: 20Z
  2. Identyfikator jest częścią adresu URL, więc tak, użyj PUT, jeśli znasz adres URL (który zawiera identyfikator).
    2013-10-29 22: 02: 53Z
  3. Nie, adres URL jest określany przez serwer, a identyfikator nie musi być częścią adresu URL. Roy Fielding powie ci ten sam lub mógłbyś po prostu przeczytać jego tezę .
    2013-10-29 23: 06: 18Z
  4. @ Joshcodes, czy to przy założeniu REST? W architekturze RESTful identyfikator elementu jest zdecydowanie częścią adresu URL, jak w: /people /123. Podoba mi się ta strona dla REST: microformats.org/wiki/rest/urls
    2013-12-26 19: 10: 14Z
  5. @ Beez link mircoformats sugeruje, że serwery mogą uporządkować swoje adresy URL, ale serwer określa adres URL . Klient, który nigdy nie ma. Zobacz moją odpowiedź lub powiązaną z nią artykuł , jeśli tego nie rozumiesz.
    2014-01-07 17: 11: 35Z

Nowa odpowiedź (teraz lepiej rozumiem REST):

PUT jest jedynie stwierdzeniem, jakiej treści usługa powinna od teraz używać do renderowania reprezentacji zasobu zidentyfikowanego przez klienta; POST jest stwierdzeniem, jakie treści usługa powinna od teraz zawierać (być może zduplikowana), ale od serwera zależy, w jaki sposób zidentyfikować tę zawartość.

PUT x (jeśli x identyfikuje zasób ): „Zamień zawartość zasobu określonego przez x na moją treść.”

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ą treść i podaj mi identyfikator, którego mogę użyć do zidentyfikowania zasobu (starego lub nowego) zawierającego tę treść (prawdopodobnie zmieszanego z inną treścią). Wspomniany zasób powinien być identyczny lub podrzędny względem tego, co identyfikuje x . ” „Zasób y jest podrzędny względem zasobu x ” jest zazwyczaj, ale niekoniecznie, realizowany poprzez y podścieżkę x (np. x = /foo i y = /foo/bar) i modyfikacja reprezentacji zasobu x w celu odzwierciedlenia istnienie 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 REST - należy używać hypermedia zamiast konstrukcji adresu URL po stronie klienta, aby mimo wszystko przejść przez usługę.

W REST nie ma czegoś takiego jak zasób zawierający „treść”. Odnoszę się jako „treść” do danych, których usługa używa do spójnego renderowania reprezentacji. Zazwyczaj składa się z kilku powiązanych wierszy w bazie danych lub pliku (np. Pliku obrazu). Do usług należy przekonwertowanie treści użytkownika na coś, z czego usługa może korzystać, np. konwertowanie ładunku JSON na instrukcje SQL.

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

PUT /something (jeśli /something już istnieje): „Weź wszystko, co masz pod /something i zastąp je tym, co ci dam.”

PUT /something (jeśli /something jeszcze nie istnieje): „Weź to, co ci dam i umieść pod /something”.

POST /something: „Weź to, co ci dam i umieść w dowolnym miejscu pod /something tak długo, jak dasz miURL po zakończeniu. ”

    
38
2017-05-23 11: 55: 13Z
  1. Ale jak możesz użyć PUT, aby utworzyć nowy zasób, jeśli nie istnieje, podczas gdy twoja metoda generowania identyfikatorów jest w Auto Increment? Zwykle ORM automatycznie generuje identyfikator, na przykład sposób, w jaki ma on być na przykład w POST. Czy to znaczy, że jeśli chcesz zaimplementować PUT we właściwy sposób, musisz zmienić swoje automatyczne generowanie id? Jest to niezręczne, jeśli odpowiedź brzmi tak.
    2018-09-16 15: 28: 21Z
  2. @ RoniAxelrad: PUT jest jak instrukcja bazy danych "INSERT OR UPDATE", w której umieszczasz klucz w instrukcji, więc ma zastosowanie tylko wtedy, gdy nie możesz zgodzić się na kolizje. na przykład. Twoja domena ma „naturalny klucz” lub używasz guid. Test POST przypomina wstawianie do tabeli za pomocą klawisza automatycznego zwiększania. Baza danych musi poinformować, jaki identyfikator otrzymał po jej wstawieniu. Zauważ, że „INSERT OR UPDATE” zastąpi wszystkie poprzednie dane, jeśli takie istnieją.
    2018-11-26 01: 33: 41Z
  3. @ NigelThorne Dziękujemy za odpowiedź. Tak więc, jeśli na przykład próbuję wprowadzić identyfikator książki 10 za pomocą URI: książki PUT /10. Jeśli identyfikator książki 10 nie istnieje, powinienem utworzyć książkę o identyfikatorze 10? ale nie mogę kontrolować licznika ID tworzenia, ponieważ jest to automatyczny przyrost. co powinienem zrobić w takiej sytuacji?
    2018-11-27 20: 50: 43Z
  4. @ RoniAxelrad REST PUT do identyfikatora, który nie istnieje, to żądanie do serwera, aby utworzyć zasób. Nadal zależy od serwera, czy chce na to zezwolić. Serwer jest odpowiedzialny. Może odpowiedzieć „Nie, nie zrobię tego”. Robisz to już, jeśli użytkownik nie ma wystarczających uprawnień ... itd. Serwer może powiedzieć „Nie”. REST to konwencja, która pozwala nam zdefiniować znaczenie różnych typów żądań ... serwer decyduje, co zrobić z tymi żądaniami w oparciu o logikę biznesową :) Nawet jeśli mówi „nie”, to nadal następuje REST:)
    2018-12-03 07: 03: 30Z

Krótka odpowiedź:

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

Długa odpowiedź:

POST:

  • POST służy do wysyłania danych do serwera.
  • Przydatne, gdy adres URL zasobu to nieznany

PUT:

  • PUT służy do transferu stanu na serwer
  • Przydatne, gdy adres URL zasobu jest znany

Dłuższa odpowiedź:

Aby to zrozumieć, musimy zadać sobie pytanie, dlaczego PUT jest wymagane, jakie były problemy, które PUT próbował rozwiązać, że POST nie mógł.

Z punktu widzenia architektury REST nie ma znaczenia. Moglibyśmy też żyć bez PUT. Jednak z punktu widzenia dewelopera klienta znacznie ułatwiło mu to życie.

Przed wprowadzeniem PUT klienci nie mogli bezpośrednio poznać adresu URL wygenerowanego przez serwer lub jeśli wszystko to wygenerowało lub czy dane do wysłania na serwer są już zaktualizowane. PUT zwolnił dewelopera z tych wszystkich bólów głowy. PUT jest idempotentny, PUT obsługuje warunki wyścigu, a PUT pozwala klientowi wybrać adres URL.

    
37
2017-10-21 13: 03: 18Z
  1. Twoja krótka odpowiedź może być BARDZO zła. HTTP PUT można dowolnie powtarzać przez proxy HTTP. I tak, jeśli PUT rzeczywiście wykonuje SQL INSERT, może się nie powieść po raz drugi, co oznacza, że ​​zwróci inny wynik, a więc nie będzie IDEMPOTENT (co jest różnicą między PUT i POST)
    2018-04-30 17: 27: 03Z

Ruby on Rails 4.0 użyje metody „PATCH” zamiast PUT do częściowych aktualizacji.

RFC 5789 mówi o PATCH (od 1995):

  

Nowa metoda jest konieczna do poprawieniazapewnić interoperacyjność i zapobiegać      błędy. Metoda PUT jest już zdefiniowana, aby zastąpić zasób      z kompletnym nowym ciałem i nie można go ponownie użyć do częściowych zmian.      W przeciwnym razie mogą uzyskać serwery proxy i pamięci podręczne, a nawet klientów i serwery      zdezorientowany co do wyniku operacji. POST jest już używany, ale      bez szerokiej interoperacyjności (dla jednego nie ma standardowego sposobu      odkryj obsługę formatu łat). PATCH został wspomniany we wcześniejszym HTTP      specyfikacje, ale nie do końca zdefiniowane.

" Edge Rails: PATCH to nowa podstawowa metoda HTTP do aktualizacji - wyjaśnia.

    
35
2017-09-16 20: 17: 52Z

Ryzykując powtórzenie tego, co już powiedziano, ważne jest, aby pamiętać, że PUT oznacza, że ​​klient kontroluje, czym będzie URL , podczas tworzenia zasobu. Tak więc wybór między PUT a POST będzie dotyczył tego, jak bardzo możesz zaufać klientowi, aby zapewnić poprawne, znormalizowane URL , które są spójny z dowolnym schematem URL.

Gdy nie możesz w pełni zaufać klientowi, aby zrobić to, co właściwe, byłoby bardziej odpowiednie jest użycie POST do utworzenia nowego elementu, a następnie wysłanie adresu URL do klienta w odpowiedzi.

    
27
2014-08-28 09: 17: 34Z
  1. Jestem trochę spóźniony na to - ale ktoś, kto powiedział coś podobnego na innej stronie, może go kliknąć. Jeśli tworzysz zasób i używasz automatycznie zwiększanego identyfikatora jako „identyfikatora” zamiast nazwy przypisanej przez użytkownika, powinien to być test POST.
    2012-02-03 18: 51: 40Z
  2. To nie do końca prawda - PUT może nadal tworzyć zasób, odwołując się do niego nie kanoniczną nazwą, o ile w odpowiedzi serwer zwróci Location nagłówek, który robi zawiera kanoniczną nazwę zasobu.
    2012-10-19 16: 08: 58Z
  3. @ Joshcodes nie zapomnij, że możesz mieć wiele URI odwołujących się do tego samego podstawowego zasobu. Tak więc, jak powiedział Ether, jest to dobra rada, klient może PUT na adres URL (który może być bardziej semantyczny, np. PUT /X-files/series/4/episodes/max), a serwer odpowie URI, który zapewnia krótki kanoniczny unikalny link do tego nowego zasobu (np. /X-Ffiles/episodes/91)
    2015-06-08 08: 02: 33Z
  4. @ thecoshman Problem polega na tym, że struktura adresu URL nie należy do klienta. Czytanie o samoodkrywaniu (także części REST) ​​może pomóc to wyjaśnić.
    2015-06-08 17: 50: 32Z
  5. @ Joshcodes, a następnie przez tę logikę, klient nie powinien nigdy używać PUT do tworzenia, ponieważ nie powinni się martwić o podanie adresu URL. No cóż ... chyba że serwer podał adres URL do PUT, jeśli klient chce go umieścić ... coś takiego jak „PUT /comments /new” i serwer może odpowiedzieć „204 /comments /234532”, ale to wydaje się trochę RPC do mnie, klient powinien po prostu POST na /komentarze ...
    2015-06-09 16: 18: 27Z

W bardzo prosty sposób biorę przykład z osi czasu Facebooka.

Przypadek 1: Kiedy publikujesz coś na osi czasu, jest to nowy nowy wpis. 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, utworzy on również nowy wpis w bazie danych, więc zastosowana zostanie metoda POST.

Przypadek 3: Jeśli twój przyjaciel edytuje swój komentarz, w tym przypadku mieli identyfikator komentarza, więc zaktualizują istniejący komentarz zamiast tworzyć nowy wpis w bazie danych. W związku z tymdla tego typu operacji użyj metody PUT, ponieważ jest ona idempotentna. *

W jednym wierszu użyj POST , by dodać nowy wpis w bazie danych i PUT , by zaktualizować coś w bazie danych.

    
22
2017-10-21 12: 49: 12Z
  1. Jeśli komentarz jest obiektem z właściwościami, takimi jak identyfikator użytkownika, data utworzenia, komunikat z komentarzem itp., a podczas edycji tylko komentarz jest aktualizowany, PATCH należy zrobić tutaj?
    2017-08-12 10: 47: 45Z
  2. PUT jest używany przez FB do aktualizacji komentarza, ponieważ istniejący zasób jest aktualizowany i to właśnie robi PUT (aktualizuje zasób). PUT zdaje się być idempotentny, w przeciwieństwie do POST. Czasownik HTTP będący idempotentem wpływa na obsługę błędów, ale nie narzuca użycia. Zobacz moją odpowiedź, aby uzyskać bardziej szczegółowe wyjaśnienie: stackoverflow.com/questions/630453/put-vs-post-in-rest/…
    2018-06-19 12: 57: 06Z

Najważniejszym czynnikiem jest niezawodność . Jeśli wiadomość POST zostanie utracona, stan systemu jest niezdefiniowany. Automatyczne odzyskiwanie jest niemożliwe. W przypadku komunikatów PUT stan jest niezdefiniowany tylko do pierwszego udanego ponowienia.

Na przykład tworzenie transakcji kartą kredytową za pomocą POST może nie być dobrym pomysłem.

Jeśli zdarzy ci się mieć automatycznie wygenerowane URI w swoim zasobie, możesz nadal używać PUT, przekazując wygenerowany URI (wskazujący na pusty zasób) klientowi.

Inne uwagi:

  • POST unieważnia buforowane kopie całego zasobu zawierającego (lepsza spójność)
  • Odpowiedzi PUT nie mogą być buforowane, podczas gdy odpowiedzi POST (Wymagaj lokalizacji treści i wygaśnięcia)
  • PUT jest mniej obsługiwane przez np. Java ME, starsze przeglądarki, zapory ogniowe
20
2012-02-10 05: 53: 13Z
  1. To jest nieprawidłowe. W przypadku POST stan jest również niezdefiniowany tylko do pierwszego udanego ponowienia. Następnie serwer akceptuje POST (komunikat nigdy nie dotarł), zgłasza konflikt 409 dla duplikatu identyfikatora (wiadomość dotarła, odpowiedź została utracona) lub innej prawidłowej odpowiedzi.
    2014-04-24 12: 13: 04Z
  2. Generalnie użytkownik nie byłby w stanie bezpiecznie ponowić operacji POST, ponieważ operacja POST nie daje żadnej gwarancji, że dwie operacje będą miały taki sam efekt jak jeden. Termin „ID” nie ma nic wspólnego z HTTP. Identyfikator URI identyfikuje zasób.
    2014-07-25 05: 48: 18Z
  3. Użytkownik może "bezpiecznie" ponowić operację POST tyle razy, ile chce. Otrzyma po prostu błąd duplikatu ID (zakładając, że zasób ma identyfikator) lub błąd powielonych danych (zakładając, że jest to problem, a zasób nie ma identyfikatorów). /div>
    2014-07-27 02: 10: 02Z
  4. Uderza głową w ścianę. HTTP nie ma rozwiązania problemu niezawodności, a to nie jest dobrze rozumiane, mało omawiane i po prostu nie jest uwzględniane w większości aplikacji internetowych. @Joshcodes Mam odpowiedź na to pytanie. Zasadniczo zgadzam się z Hansem. Jest problem.
    2018-06-13 08: 21: 20Z
  5. @ bbsimonbb, HTTP ma solidny i dobrze udokumentowany zestaw odpowiedzi na błędy. Moja odpowiedź na to pytanie ( stackoverflow.com /questions /630453 /put-vs-post-in-rest /… ) omawia sposób korzystania z http zgodnie ze specyfikacją w celu osiągnięcia spójności.
    2018-06-19 12: 50: 19Z

Wydaje się, że zawsze istnieje pewne zamieszanie co do tego, kiedy użyć HTTP POST w porównaniu z metodą HTTP PUT dla usług REST. Większość programistów będzie próbować powiązać operacje CRUD bezpośrednio z metodami HTTP. Twierdzę, że nie jest to poprawne i nie można po prostu powiązać pojęć CRUD z metodami HTTP. To jest:

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 odpowiednio GET i DELETE. Jednak zamieszanie dotyczy operacji C (reate) i U (update). W niektórych przypadkach można użyć PUT dla kreacji, podczas gdy w innych przypadkach wymagany jest test POST. Niejednoznaczność polega na definicji metody HTTP PUT w porównaniu z metodą HTTP POST.

Zgodnie ze specyfikacjami HTTP 1.1 metody GET, HEAD, DELETE i PUT muszą być idempotentne, a metoda POST nie jest idempotentna. Oznacza to, że operacja jest idempotentna, jeśli może być wykonana na zasobie raz lub wiele razy i zawsze zwraca ten sam stan tego zasobu. Natomiast operacja bez idempotentu może zwrócić zmodyfikowany stan zasobu z jednego żądania do drugiego. Stąd w przypadku operacji bez idempotentu nie ma gwarancji, że otrzymamy ten sam stan zasobu.

Opierając się na powyższej definicji idempotentu, moje zastosowanie metody HTTP PUT w porównaniu z metodą HTTP POST dla usług REST to: 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ż 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 należy bezpośrednio korelować i odwzorowywać operacji CRUD na metody 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, użyj metody HTTP PUT. Jeśli operacja nie jest idempotentna, użyj metody HTTP POST.

    
14
2013-10-10 04: 18: 51Z
  1. Update = > HTTP POST: POST nie służy do aktualizacji
    2016-01-30 00: 57: 59Z

Czytelnicy nowi w tym temacie będą zaskoczeni niekończącą się dyskusją na temat tego, co powinien zrobić, oraz względnym brakiem lekcji z doświadczenia. Fakt, że REST jest „preferowany” w stosunku do SOAP, to, jak przypuszczam, uczenie się na wysokim poziomie z doświadczenia, ale dobroć musieliśmy postępować stamtąd? Jest rok 2016. Rozprawa Roya miała miejsce w 2000 roku. Co rozwinęliśmy? Fajnie było? Czy łatwo było się zintegrować? Wspierać? Czy poradzi sobie z rozwojem smartfonów i niestabilnych połączeń mobilnych?

Według ME, rzeczywiste sieci są zawodne. Limit czasu żądań. Połączenia są resetowane. Sieci znikają godzinami lub dniami. Pociągi jadą do tuneli z mobilnymi użytkownikami na pokładzie. W przypadku każdej prośby (co okazuje się potwierdzone we wszystkich tych dyskusjach) prośba może wpaść do wody po drodze lub odpowiedź może spaść w wodzie w drodze powrotnej. W tych warunkach wydawanie żądań PUT, POST i DELETE bezpośrednio przeciwko materialnym zasobom zawsze wydawało mi się trochę brutalne i naiwne.

HTTP nie robi nic, aby zapewnić niezawodne zakończenie odpowiedzi na żądanie, a to jest w porządku, ponieważ jest to właściwie zadanie aplikacji obsługujących sieć. Opracowując taką aplikację, możesz przeskakiwać przez 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 duplikaty żądań. Wracając do klienta, musisz skakać przez obręcze, aby zinterpretować te błędy, refetch, revalidate i repost.

Lub możesz to zrobić : rozważ niebezpieczne żądania jako tymczasowe zasoby dla pojedynczego użytkownika (nazwijmy je działaniami). Klienci żądają nowego „działania” na zasobie merytorycznym z pustym POST do zasobu. POST zostanie użyty tylko w tym celu. Po bezpiecznym posiadaniu identyfikatora URI świeżo wybitej akcji klient przekazuje niebezpieczne żądanie do identyfikatora URI akcji, nie jest zasobem docelowym . Rozwiązywanie akcji i upda„prawdziwym” zasobem jest właściwie zadanie twojego API i jest ono oddzielone od niewiarygodnej sieci.

Serwer robi interesy, zwraca odpowiedź i przechowuje ją w stosunku do uzgodnionego identyfikatora URI działania . Jeśli coś pójdzie nie tak, klient powtarza żądanie (naturalne zachowanie!), A jeśli serwer już to widział, powtarza zapisaną odpowiedź i nic więcej nie robi .

Szybko zauważysz podobieństwo z obietnicami: tworzymy i zwracamy symbol zastępczy wyniku przed zrobieniem czegokolwiek. Podobnie jak obietnica, akcja może odnieść sukces lub zakończyć się niepowodzeniem, ale jej wynik można wielokrotnie pobierać.

Co najważniejsze, dajemy aplikacjom wysyłającym i odbierającym szansę na połączenie unikalnie zidentyfikowanej akcji z unikalnością w odpowiednich środowiskach. I możemy zacząć żądać i egzekwować odpowiedzialne zachowanie klientów: powtarzaj swoje żądania tak, jak chcesz, ale nie generuj nowej akcji, dopóki nie będziesz w posiadaniu ostatecznego wyniku z istniejącego. /p>

Z tego powodu wiele drażliwych problemów odchodzi. Powtarzające się żądania wstawiania nie tworzą duplikatów i nie tworzymy prawdziwego zasobu, dopóki nie będziemy w posiadaniu danych. (kolumny bazy danych mogą pozostać niezawarte). Powtarzające się żądania aktualizacji nie trafią na niezgodne stany i nie zastąpią kolejnych zmian. Klienci mogą (ponownie) pobierać i bezproblemowo przetwarzać oryginalne potwierdzenie z dowolnego powodu (klient się zawiesił, brakowało odpowiedzi itp.).

Kolejne żądania usunięcia mogą wyświetlać i przetwarzać oryginalne potwierdzenie bez trafienia w błąd 404. Jeśli sprawy trwają dłużej, niż się spodziewamy, możemy zareagować tymczasowo i mamy miejsce, w którym klient może sprawdzić, czy nie ma ostatecznego wyniku. Najładniejszą częścią tego wzoru jest jego własność Kung-Fu (Panda). Mamy słabość, skłonność klientów do powtarzania żądania za każdym razem, gdy nie rozumieją odpowiedzi, i zamieniają ją w siłę :-)

Zanim powiesz mi, że nie jest to RESTful, rozważ liczne sposoby respektowania zasad REST. Klienci nie tworzą adresów URL. Interfejs API pozostaje wykrywalny, choć z niewielką zmianą semantyki. Stosowane są czasowniki HTTP. Jeśli uważasz, że jest to ogromna zmiana do wdrożenia, mogę powiedzieć z doświadczenia, że ​​tak nie jest.

Jeśli uważasz, że będziesz miał ogromne ilości danych do przechowywania, porozmawiajmy na temat woluminów: typowe potwierdzenie aktualizacji to ułamek kilobajta. HTTP obecnie daje minutę lub dwie, aby odpowiedzieć definitywnie. Nawet jeśli przechowujesz akcje tylko przez tydzień, klienci mają duże szanse na nadrobienie zaległości. Jeśli masz bardzo duże wolumeny, możesz chcieć dedykowanego magazynu wartości kluczowych zgodnego z kwasem lub rozwiązania w pamięci.

    
14
2018-05-23 14: 06: 30Z
  1. Czy przechowywanie odpowiedzi nie będzie jak utrzymywanie sesji? Które spowodowałyby (poziome) problemy ze skalowaniem.
    2018-08-21 17: 57: 34Z
  

serwer pochodzenia może utworzyć zasób z tym URI

Używasz więc POST i prawdopodobnie, ale nie koniecznie PUT do tworzenia zasobów. Nie musisz obsługiwać obu. Dla mnie POST jest całkowicie wystarczający. To jest decyzja projektowa.

Jak wspomniałeś w swoim cytacie, PUT używasz do tworzenia zasobów, które nie są przypisane do IRI, a mimo to chcesz utworzyć zasób. Na przykład PUT /users/123/password zwykle zastępuje stare hasło nowym hasłem, ale można go użyć do utworzenia hasła, jeśli jeszcze nie istnieje (na przykład przez świeżo zarejestrowanych użytkowników lub przez przywrócenie zablokowanych użytkowników).

    
13
2017-10-21 12: 41: 52Z
  1. Myślę, że udało ci się zrobić jeden z kilku dobrych przykładów użycia PUT, dobrze zrobione.
    2015-06-08 08: 13: 00Z

Oprócz różnic sugerowanych przez innych, chcę dodać jeszcze jedną.

W metodzie POST możesz wysyłać wiadomości o treści w form-data

W metodzie PUT musiszwysłać params ciała w x-www-form-urlencoded

Nagłówek Content-Type:application/x-www-form-urlencoded

Zgodnie z tym nie można wysyłać plików ani danych wieloczęściowych w metodzie PUT

EDIT

  

Typ zawartości „application /x-www-form-urlencoded” jest nieefektywny   do wysyłania dużych ilości danych binarnych lub zawierających tekst   znaki spoza ASCII. Typ zawartości „dane wieloczęściowe /dane formalne” powinien być   używany do przesyłania formularzy zawierających pliki, dane inne niż ASCII i   dane binarne.

Co oznacza, że ​​musisz przesłać

  

pliki, dane inne niż ASCII i dane binarne

powinieneś użyć metody POST

    
12
2018-10-01 09: 33: 47Z
  1. Dlaczego nie zostało to potwierdzone? Jeśli to prawda, jest to krytyczne wyróżnienie, prawda?
    2018-09-29 03: 02: 01Z
  2. Stałem w obliczu implementacji interfejsu API do aktualizacji profilu, w tym do przesyłania zdjęć profilu użytkownika. Następnie przetestowałem go z listonoszem, Ajaxem, curl PHP i laravel 5.6 jako backendem.
    2018-09-29 06: 54: 18Z

Zamierzam wylądować w następujący sposób:

PUT odnosi się do zasobu identyfikowanego przez URI. W tym przypadku aktualizujesz go. Jest to część trzech czasowników odnoszących się do zasobów - usuń i zostań dwoma pozostałymi.

POST jest zasadniczo wiadomością w formie swobodnej, której znaczenie jest zdefiniowane „poza pasmem”. Jeśli wiadomość można zinterpretować jako dodanie zasobu do katalogu, byłoby OK, ale w zasadzie musisz zrozumieć wiadomość, którą wysyłasz (publikując), aby wiedzieć, co stanie się z zasobem.


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

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

PUT nie musi być kreacją; usługa może się nie powieść, jeśli zasób nie został jeszcze utworzony, ale w inny sposób zaktualizować. Lub odwrotnie - może utworzyć zasób, ale nie zezwalać na aktualizacje. Jedyne, co wymaga PUT, to to, że wskazuje konkretny zasób, a jego ładunek reprezentuje ten zasób. Udane PUT oznacza (wykluczając zakłócenia), że GET pobierze ten sam zasób.


Edytuj: Jeszcze jedna rzecz - PUT może utworzyć, ale jeśli tak się stanie, identyfikator musi być naturalnym identyfikatorem - AKA to adres e-mail. W ten sposób, gdy dwa razy PUT, drugi jest aktualizacją pierwszego. To sprawia, że ​​ idempotentuje .

Jeśli identyfikator zostanie wygenerowany (na przykład nowy identyfikator pracownika), to drugie PUT z tym samym adresem URL utworzy nowy rekord, który narusza regułę idempotent. W tym przypadku czasownik oznaczałby POST, a komunikat (nie zasób) polegałby na utworzeniu zasobu przy użyciu wartości zdefiniowanych w tym komunikacie.

    
11
2017-10-21 12: 32: 49Z

Przypuszcza się, że semantyka jest inna, w tym „PUT”, jak „GET” ma być idempotentne - co oznacza, że ​​możesz wielokrotnie żądać tego samego PUT, a wynik będzie taki, jakbyś wykonał go tylko raz .

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

Kiedy PUT przypisujesz do konkretnego adresu URL, to dzieje się tak, że powinien on zostać zapisany pod tym adresem URL lub czymś podobnym.

Gdy POST na zasób pod określonym adresem URL, często wysyłasz pokrewną informację do tego adresu URL. Oznacza to, że zasób pod adresem URL już istnieje.

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

Jeśli chodzi o modyfikowanie 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 mye POST.

Należy jednak pamiętać, że nie wszystkie nowoczesne przeglądarki obsługują czasowniki HTTP inne niż GET lub POST.

    
9
2011-10-23 20: 07: 55Z
  1. To, co opisujesz POST tak, jak powinien zachowywać się PATCH. POST ma oznaczać coś bardziej zbliżonego do „dołączania”, jak w „publikuj na liście dyskusyjnej”.
    2014-11-28 15: 57: 25Z

W większości przypadków użyjesz ich w ten sposób:

  • POST zasób w kolekcji
  • PUT zasób określony przez collection /: id

Na przykład:

  • POST /elementy
  • PUT /przedmioty /1234

W obu przypadkach treść żądania zawiera dane do utworzenia lub zaktualizowania zasobu. Z nazw tras powinno być oczywiste, że POST nie jest idempotentny (jeśli wywołasz to 3 razy, utworzy 3 obiekty), ale PUT jest idempotentny (jeśli nazwiesz to 3 razy, wynik jest taki sam). PUT jest często używany do operacji „upsert” (tworzenie lub aktualizacja), ale zawsze możesz zwrócić błąd 404, jeśli chcesz go użyć tylko do modyfikacji.

Zauważ, że POST „tworzy” nowy element w kolekcji, a PUT „zastępuje” element pod danym adresem URL, ale bardzo częstą praktyką jest używanie PUT do częściowych modyfikacji, to znaczy użyj go tylko do aktualizacji istniejące zasoby i modyfikuj tylko dołączone pola w ciele (ignorując pozostałe pola). Jest to technicznie niepoprawne, jeśli chcesz być purystą REST, PUT powinien zastąpić cały zasób i powinieneś użyć PATCH do częściowej aktualizacji. Osobiście nie dbam o to, aby zachowanie było jasne i spójne we wszystkich punktach końcowych interfejsu API.

Pamiętaj, że REST to zestaw konwencji i wytycznych, które ułatwiają korzystanie z interfejsu API. Jeśli skończysz ze skomplikowaną pracą tylko po to, by zaznaczyć pole „RESTfull”, pokonujesz cel;)

    
7
2017-06-21 17: 38: 44Z

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

Bądźmy bardzo jasne i bezpośrednie. Jeśli jesteś programistą .NET pracującym z Web API, fakty są (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.

Pewnie „możesz” użyć „POST” do aktualizacji, ale po prostu postępuj zgodnie z konwencjami określonymi dla danej struktury. W moim przypadku jest to .NET /Web API, więc PUT jest na AKTUALIZACJĘ , nie ma debaty.

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

    
7
2017-07-22 11: 48: 51Z

Jeśli znasz operacje na bazach danych, są

  1. Wybierz
  2. Wstaw
  3. Aktualizacja
  4. Usuń
  5. Scal (zaktualizuj, jeśli już istnieje, else wstaw)

Używam PUT do scalania i aktualizacji, takich jak operacje, i używam POST do wstawiania.

    
6
2016-06-29 21: 13: 07Z

Oto prosta zasada:

PUT na adres URL powinien być używany do aktualizowania lub tworzenia zasobu, który może znajdować się pod tym adresem URL.

POST na adres URL powinien być używany do aktualizacji lub utworzenia zasobu, który znajduje się pod jakimś innym („podrzędnym”) adresem URL lub nie można go zlokalizować za pośrednictwem protokołu HTTP.

    
6
2017-09-16 20: 24: 31Z
  1. PUT nie służy do aktualizacji, jest do zastąpienia, zauważ, że aby utworzyć, niczego nie zastępujesz. POST nie jest absolutnie przeznaczony do aktualizacji w żadnej formie.
    2015-06-08 08: 10: 32Z
  2. Czy specyfikacja http mówi tak? A może opierasz swój komentarz na czymś innym?
    2016-07-10 20: 41: 57Z
  3. To jest po prostu zdrowy rozsądek, w jaki sposób aktualizujesz coś, gdy nie wiesz, co aktualizujesz? POST służy do tworzenia nowego zasobu.
    2016-07-27 09: 23: 42Z
  4. thecoshman - nadużywasz tutaj semantyki - zastąpienie może być aktualizacją, jeśli jest to ten sam zasób z kilkoma różnicami. Zastąpienie jest ważne tylko dla put, jeśli zamiennik jest używany do zmiany tego samego zasobu. Zastąpienie nowego i innego zasobu jest nieprawidłowe (usuń stare i dodaj nowe?), Zwłaszcza jeśli „nowy” zasób nie ma naturalnego identyfikatora. POST, OTOH, to coś, co może tworzyć, aktualizować, zastępować i usuwać - korzystanie z posta zależy od tego, czy istnieje komunikat do zinterpretowania, np. „Zastosuj rabat”, który może, ale nie musi, zmienić zasób w zależności od logika.
    2016-12-28 16: 54: 04Z
  5. Jeśli chodzi o twój drugi komentarz - co powiesz na „zdobycie” zasobu, zmodyfikowanie pól, które są potrzebne, a następnie odłożenie go? A jeśli chodzi o to, czy zasób pochodzi z innego źródła, ale używa naturalnego identyfikatora (identyfikatora zewnętrznego) - to w naturalny sposób zaktualizowałby zasób pod adresem URL po zmianie oryginalnych danych.
    2016-12-28 16: 56: 26Z

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

        
    5
    2014-10-13 09: 59: 32Z
    1. W przeważającej części, od przeczytania całego tego hałasu, wydajesz się na kuli. Powiedziałbym jednak, że powinniśmy odwoływać się do PUT jako metody zastępowania, a nie do tworzenia /aktualizacji. Myślę, że lepiej w jednym opisuje to, co robi.
      2015-06-08 08: 15: 20Z
źródło umieszczone tutaj