Jaka jest przydatność metod żądań HTTP PUT i DELETE?


89

Dużo czytałem na ten temat, ale nie jestem w stanie wyciągnąć wniosków na ten temat.

Ale nigdy nie korzystałem z metod żądania HTTP PUT lub DELETE. Moją tendencją jest używanie GET, gdy statystyka systemu (moja aplikacja lub strona internetowa) może nie ulec zmianie (np. Lista produktów) i używanie POST, gdy ma to wpływ (złożone zamówienie). Czy to nie wystarczy, czy czegoś mi brakuje?


2
PUT / DELETE jest łatwiejsze do kodowania, ale trudniejsze do skonfigurowania (pod względem bezpieczeństwa - katalog vhost / apache). Moja skromna opinia ... bez nich możesz żyć.
Najzero

5
@Najzero tak, jestem niezmiernie szczęśliwy bez nich :) ale potrzebuję odpowiedzi, dlaczego tam są ?? przeczytałem kilka rzeczy, ale nie mogłem sobie z tym
poradzić

Odpowiedzi:


88

DELETE służy do usuwania zasobu żądania:

Metoda DELETE żąda, aby serwer pochodzenia usunął zasób identyfikowany przez identyfikator URI żądania. Ta metoda MOŻE zostać zastąpiona przez interwencję człowieka (lub w inny sposób) na serwerze pochodzenia. Klient nie może zagwarantować, że operacja została wykonana, nawet jeśli kod stanu zwrócony z serwera pochodzenia wskazuje, że akcja została zakończona pomyślnie…

PUT służy do umieszczania lub aktualizowania zasobu na serwerze:

Metoda PUT żąda, aby zamknięta jednostka była przechowywana pod podanym identyfikatorem URI żądania. Jeśli identyfikator Request-URI odwołuje się do już istniejącego zasobu, dołączona jednostka POWINNA być traktowana jako zmodyfikowana wersja tej, która znajduje się na serwerze pochodzenia. Jeśli identyfikator Request-URI nie wskazuje na istniejący zasób, a ten identyfikator URI może zostać zdefiniowany jako nowy zasób przez żądającego agenta użytkownika, serwer pochodzenia może utworzyć zasób z tym identyfikatorem URI…

Aby zapoznać się z pełną specyfikacją, odwiedź:

Ponieważ obecne przeglądarki niestety nie obsługują żadnych innych czasowników niż POST i GET w formularzach HTML , zwykle nie można w nich w pełni wykorzystać HTTP (chociaż nadal można przejąć ich przesyłanie za pomocą JavaScript). Brak obsługi tych metod w formularzach HTML doprowadził do identyfikatorów URI zawierających czasowniki, jak na przykład

POST http://example.com/order/1/delete

lub nawet gorzej

POST http://example.com/deleteOrder/id/1

efektywne tunelowanie semantyki CRUD przez HTTP. Ale czasowniki nigdy nie miały być częścią identyfikatora URI. Zamiast tego protokół HTTP zapewnia już mechanizm i semantykę CRUD zasobu (np. Zamówienia) za pośrednictwem metod HTTP. HTTP to protokół, a nie tylko usługa tunelowania danych.

Aby usunąć zasób na serwerze internetowym, zadzwoń

DELETE http://example.com/order/1

i aby go zaktualizować, zadzwonisz

PUT http://example.com/order/1

i podaj zaktualizowaną Reprezentację Zasobów w treści PUT, aby serwer sieciowy mógł następnie zastosować.

Tak więc, jeśli tworzysz jakiegoś klienta dla REST API , prawdopodobnie zmusisz go do wysyłania żądań PUT i DELETE. Może to być klient wbudowany w przeglądarkę, np. Wysyłający żądania przez JavaScript, może to być narzędzie działające na serwerze itp.

Aby uzyskać więcej informacji, odwiedź:


7
Przeglądarki mogą wysyłać PUT i DELETE za pomocą JavaScript!
Joe

5
@Joe Tak, ale metody formularzy HTML nie. Dopóki nie jest to obsługiwane po wyjęciu z pudełka, musisz przejść przez obręcze, aby działało. To jedna z głównych porażek producentów przeglądarek.
Gordon

3
Oczywiście, że nie, formularze są przeznaczone do POST i GET. To jest w projekcie HTML. Nie jest prawdą, że PUT i DELETE nie są obsługiwane. Przeglądarki obsługują HTML i HTTP.
Joe

@Joe prawdopodobnie nie mamy wtedy takiej samej definicji „podpór”. Większość przeglądarek obsługuje JavaScript i tak, JavaScript może wykonywać żądania HTTP, ale nadal muszę to zaprogramować , powiązać kod z niektórymi elementami UI i najpierw dostarczyć go do klienta.
Gordon

4
Przeglądarka wyświetla pustą stronę, chyba że napiszesz jakiś kod HTML. Tak, być może musimy się nie zgodzić. Nie zgadzam się!
Joe

26

Użycie czasownika żądania HTTP, takiego jak GET, POST, DELETE, PUT itp ... umożliwia tworzenie aplikacji internetowych zgodnych z REST. Przeczytaj o tym tutaj: http://en.wikipedia.org/wiki/Representational_state_transfer

Najłatwiejszym sposobem dostrzeżenia korzyści płynących z tego jest spojrzenie na ten przykład. Każdy framework MVC ma, Router/Dispatcherktóry mapuje adresy URL do actionControllers. Tak więc adres URL taki: /blog/article/1wywołałby blogController::articleAction($id); Teraz ten router zna tylko adres URL lub/blog/article/1/

Ale jeśli ten router byłby świadomy całego obiektu żądania HTTP zamiast tylko adresu URL, mógłby mieć dostęp do czasownika żądania HTTP (GET, POST, PUT, DELETE ...) i wielu innych przydatnych informacji na temat bieżącego żądania HTTP.

Umożliwiłoby to skonfigurowanie aplikacji tak, aby mogła akceptować ten sam adres URL i mapować go na różne kontrolery akcji w zależności od zlecenia HTTP Request.

Na przykład:

jeśli chcesz odzyskać artykuł 1, możesz to zrobić:

GET /blog/article/1 HTTP/1.1

ale jeśli chcesz usunąć artykuł 1, zrobisz to:

DELETE /blog/article/1 HTTP/1.1

Zauważ, że oba żądania HTTP mają ten sam identyfikator URI, / blog / article / 1, jedyną różnicą jest czasownik HTTP Request. Na podstawie tego czasownika twój router może wywołać inny kontroler actionController. Umożliwia to tworzenie zgrabnych adresów URL.

Przeczytaj te dwa artykuły, mogą ci pomóc:

Symfony 2 - Podstawy HTTP

Symfony 2 - routing

Te artykuły dotyczą frameworka Symfony 2, ale mogą pomóc ci dowiedzieć się, jak działają żądania i odpowiedzi HTTP.

Mam nadzieję że to pomoże!


6
mimo że nie jestem ich przyjacielem, ładnie wyjaśnione +1 ;-)
Najzero

1
Ta odpowiedź najlepiej wyjaśnia znaczenie czasowników HTTP i zgodność z usługami prawdziwie RESTful oraz ich zaletami. Jeśli nie używasz, powiedzmy HTTP DELETE, możesz mieć (2) akcje POST w kontrolerze: 1 for Createi 1 for Delete. Jeśli to zrobisz, Twoje następne wyszukiwanie będzie polegało na pytaniuJak mieć wiele akcji Post na jednym kontrolerze ”: P. Nie żeby to było okropne, ale tracisz możliwość zaimplementowania unikalnego zasobu poprzez akcję czasownika, w przeciwieństwie do konieczności jawnego podawania nazwy akcji w identyfikatorze URI.
atconway

3

Chociaż ryzykuję, że nie będę popularny, mówię, że obecnie nie są one przydatne .

Myślę, że były dobrze zaplanowane i przydatne w przeszłości, kiedy na przykład DELETE powiedział serwerowi, aby usunął zasób znaleziony pod podanym adresem URL, a PUT (z jego siostrzaną PATCH) powiedział serwerowi, aby dokonał aktualizacji w idempotentny sposób.

Rzeczy ewoluowały, a adresy URL stały się wirtualne (patrz na przykład przepisywanie adresu URL ), co powoduje, że zasoby tracą swoje pierwotne znaczenie prawdziwego folderu / podfordera / pliku, a zatem czasowniki akcji CRUD objęte metodami protokołu HTTP (GET, POST, PUT / PATCH, DELETE) utracone ścieżki .

Weźmy przykład:

  • / api / entity / list / {id} a GET / api / entity / {id}
  • / api / entity / add / {id} vs POST / api / entity
  • / api / entity / edit / {id} a PUT / api / entity / {id}
  • / api / entity / delete / {id} vs DELETE / api / entity / {id}

Po lewej stronie nie jest zapisana metoda HTTP, w zasadzie nie ma to znaczenia (wystarczą POST i GET), a po prawej stosowane są odpowiednie metody HTTP.

Prawa strona wygląda elegancko, czysto i profesjonalnie. Wyobraź sobie, że teraz musisz utrzymywać kod, który korzystał z eleganckiego interfejsu API i musisz szukać, gdzie jest wykonywane wywołanie usunięcia. Będziesz szukać „api / entity”, a wśród wyników będziesz musiał zobaczyć, który z nich wykonuje DELETE. Albo co gorsza, masz młodszego programistę, który przez pomyłkę przełączył PUT na DELETE i jak URL to to samo się stało.

Moim zdaniem umieszczenie czasownika akcji w adresie URL ma zalety w porównaniu z użyciem odpowiedniej metody HTTP dla tej akcji, nawet jeśli nie jest tak elegancka. Jeśli chcesz zobaczyć, gdzie jest wykonywane wywołanie delete, po prostu wyszukaj „api / entity / delete”, a znajdziesz je od razu.

Budowanie interfejsu API bez całej tablicy metod HTTP ułatwia późniejsze wykorzystanie i konserwację


1

Bezpieczne metody: pobierz zasób / brak modyfikacji w zasobie
Idempotentne: brak zmiany stanu zasobu, jeśli żądano wiele razy
Niebezpieczne metody: tworzenie lub aktualizowanie zasobu / modyfikacja zasobu
Nie Idempotentne: zmiana stanu zasobu, jeśli żądano wiele razy

Zgodnie z twoim wymaganiem:

1) Do bezpiecznej i idempotentnej operacji (Fetch Resource) użyj --------- GET METHOD
2) Do niebezpiecznej i nie idempotentnej operacji (Insert Resource) użyj --------- POST METHOD
3) W przypadku niebezpiecznej i idempotentnej operacji (Update Resource) użyj --------- PUT METHOD
3) W przypadku niebezpiecznej i idempotentnej operacji (Delete Resource) użyj --------- DELETE METHOD

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.