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

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?

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ź:

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

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ź:

• http://martinfowler.com/articles/richardsonMaturityModel.html
• Czy metody PUT, DELETE, HEAD itp. Są dostępne w większości przeglądarek internetowych?
• Dlaczego w formularzach HTML nie ma metod PUT i DELETE
• Czy PUT i DELETE powinny być używane w formularzach?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

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!

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ę

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