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?
Odpowiedzi:
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ź:
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:
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!
Createi 1 for Delete. Jeśli to zrobisz, Twoje następne wyszukiwanie będzie polegało na pytaniu „ Jak 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.
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:
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