Oto jak może wyglądać wniosek spokojny.
POST /posts/delete_multiple HTTP/1.1
Host: www.example.com
post_ids[]=33&post_ids[]=47&post_ids[]=88
Należy pamiętać, że podczas GET
, PUT
i DELETE
mają bardzo konkretne znaczenie w kontekście odpoczynku, POST
jest bardziej niejasne i zasadniczo znaczy podjąć pewne działania. Czynność do wykonania jest podawana w adresie URL, a dodatkowe dane specyficzne dla działania są przekazywane w jednostce (treści) żądania. Używaj tylko POST
w ten sposób, gdy GET
, PUT
i DELETE
nie mają zamierzonego znaczenia.
POST
jest powszechnie interpretowany jako "tworzenie", ale nie jest to prawdą. Powszechnie używamy POST
do tworzenia nowych zasobów, gdy klient nie wie, jaki powinien być adres URL nowo utworzonego zasobu. Ale gdy klient nie może ustalić adresu URL nowo utworzonego zasobu, poprawnym czasownikiem będzie PUT
.
Podany przykład jest architektura stylu RPC gdy zamierzony operacja jest zdefiniowana w URI, a nie w metodzie HTTP. POST jest również wyraźnie zdefiniowany w [sekcja 9.5] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) standardu HTTP. Chociaż standard nie wskazuje, że POST może być użyty do przesłania danych do procesu przetwarzania danych, który nie sprawia, że użycie metody POST jest RESTful. RESTful podejście byłoby zdefiniowanie nowego zasobu, który reprezentuje zbiór innych zasobów, a następnie usunąć tę kolekcję. –
OK, a następnie 'POST/posts/batch_deletes' z tym samym obiektem-treścią. Sub-zasób (zasób 'Post :: BatchDelete') zostałby utworzony, ale byłby natychmiast uruchamiany za kulisami i niszczony natychmiastowo. Efektem działania pod-zasobu jest to, że wszystkie posty wymienione w tym pod-zasobu są również niszczone. – yfeldblum
Jednak wymaganie dwóch żądań usunięcia wielu zasobów nie jest restrykcyjne (konkretnie * wymaganie *, że * tak musi być * nie jest restful). Jest to po prostu powolne, ponieważ wymaga dwóch cykli żądanie-odpowiedź, a nie jednego. – yfeldblum