REST API - po co używać PUT DELETE POST GET?

Przeglądałem więc kilka artykułów na temat tworzenia REST API. A niektórzy z nich sugerują używanie wszystkich typów żądań HTTP: na przykład PUT DELETE POST GET. Utworzylibyśmy na przykład index.php i napisalibyśmy API w ten sposób:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

OK, przyznam - nie wiem zbyt wiele o usługach internetowych (jeszcze). Ale czy nie byłoby łatwiej po prostu zaakceptować obiekt JSON za pomocą zwykłego POSTlub GET(który zawierałby nazwę metody i wszystkie parametry), a następnie odpowiedzieć również w formacie JSON. Możemy łatwo serialize / Cofnięcie poprzez PHP json_encode()i json_decode()i robić, co chcemy z tych danych bez konieczności zajmowania się różnymi metodami żądania HTTP.

Czy coś mi brakuje?

AKTUALIZACJA 1:

Ok - po przekopaniu się przez różne API i nauczeniu się wielu rzeczy o XML-RPC , JSON-RPC , SOAP , REST doszedłem do wniosku, że ten typ API jest dobry. W rzeczywistości wymiana stosów w zasadzie używa tego podejścia w swoich witrynach i myślę, że ci ludzie wiedzą, co robią Stack Exchange API .

Pomysł RE prezentacyjny S tate T ransfer nie chodzi o dostęp do danych w najprostszy możliwy sposób.

Zasugerowałeś użycie żądań postów w celu uzyskania dostępu do JSON, który jest całkowicie prawidłowym sposobem uzyskiwania dostępu do danych / manipulowania nimi.

REST to metodologia istotnego dostępu do danych. Gdy zobaczysz żądanie w REST, powinno być natychmiast widoczne, co dzieje się z danymi.

Na przykład:

GET: /cars/make/chevrolet

prawdopodobnie zwróci listę chevy samochodów. Dobrym REST API może zawierać nawet kilka opcji wydruku w ciągu kwerendy jak ?output=jsonlub ?output=htmlktóre pozwoliłyby accessor zdecydować, jaki format informacje powinny być kodowane.

Po odrobinie myślenia o tym, jak racjonalnie włączyć wpisywanie danych do REST API, mam do wniosku, że najlepszym sposobem, aby określić typ danych jednoznacznie byłoby poprzez już istniejące rozszerzenia pliku, takie jak .js, .json, .html, lub .xml. Brakujące rozszerzenie pliku będzie miało domyślnie dowolny format (taki jak JSON); nieobsługiwane rozszerzenie pliku może zwrócić 501 Not Implementedkod stanu .

Inny przykład:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

prawdopodobnie utworzy nowy chevy malibu w bazie danych z powiązanymi kolorami. Mówię prawdopodobnie, ponieważ interfejs API REST nie musi być bezpośrednio powiązany ze strukturą bazy danych. Jest to po prostu interfejs maskujący, dzięki któremu prawdziwe dane są chronione (pomyśl o nich jak o akcesoriach i mutatorach struktury bazy danych).

Teraz musimy przejść do kwestii idempotencji . Zwykle REST implementuje CRUD przez HTTP. HTTP używa GET, PUT, POSTa DELETEdla wniosków.

Bardzo uproszczona implementacja REST może wykorzystywać następujące mapowanie CRUD:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

Występuje problem z tą implementacją: Post jest zdefiniowany jako metoda nie idempotentna. Oznacza to, że kolejne wywołania tej samej metody Post będą skutkować różnymi stanami serwera. Get, Put i Delete są idempotentne; co oznacza, że ​​wywołanie ich wielokrotnie powinno skutkować identycznym stanem serwera.

Oznacza to, że żądanie takie jak:

Delete: /cars/oldest

faktycznie można by zaimplementować jako:

Post: /cars/oldest?action=delete

Natomiast

Delete: /cars/id/123456

spowoduje ten sam stan serwera, jeśli wywołasz go raz, lub jeśli zadzwonisz 1000 razy.

Lepszym sposobem usunięcia oldestprzedmiotu byłoby zażądanie:

Get: /cars/oldest

iz IDuzyskanych danych skorzystaj w celu zgłoszenia deleteżądania:

Delete: /cars/id/[oldest id]

Problem z tą metodą mógłby wystąpić, gdyby inny /carselement został dodany między momentem /oldestzażądania a deletewydaniem.

To jest kwestia bezpieczeństwa i łatwości konserwacji.

bezpieczne metody

O ile to możliwe, należy używać „bezpiecznych” (jednokierunkowych) metod, takich jak GET i HEAD, aby ograniczyć potencjalną podatność.

metody idempotentne

O ile to możliwe, powinieneś używać metod „idempotentnych”, takich jak GET, HEAD, PUT i DELETE, które nie mogą mieć skutków ubocznych i dlatego są mniej podatne na błędy / łatwiejsze do kontrolowania.

Źródło

Krótko mówiąc, REST kładzie nacisk na rzeczowniki nad czasowniki. Gdy twoje API staje się bardziej złożone, dodajesz więcej rzeczy, a nie więcej poleceń.

Zapytałeś :

czy nie byłoby łatwiej po prostu zaakceptować obiekt JSON przez normalne $ _POST, a następnie odpowiedzieć również w formacie JSON

Z Wikipedii na REST :

Aplikacje RESTful maksymalizują wykorzystanie wcześniej istniejącego, dobrze zdefiniowanego interfejsu i innych wbudowanych funkcji zapewnianych przez wybrany protokół sieciowy oraz minimalizują dodawanie nowych funkcji specyficznych dla aplikacji.

Z tego, co (niewiele) widziałem, wydaje mi się, że zwykle osiąga się to poprzez maksymalizację wykorzystania istniejących czasowników HTTP i zaprojektowanie schematu adresu URL dla Twojej usługi, który jest tak potężny i oczywisty, jak to tylko możliwe.

Niestandardowe protokoły danych (nawet jeśli są zbudowane na podstawie standardowych, takich jak SOAP lub JSON) są odradzane i powinny być zminimalizowane, aby jak najlepiej odpowiadały ideologii REST.

Z drugiej strony, protokół SOAP RPC przez HTTP zachęca każdego projektanta aplikacji do zdefiniowania nowego, dowolnego słownika rzeczowników i czasowników (na przykład getUsers (), savePurchaseOrder (...)), zwykle nakładanych na czasownik HTTP „POST”. Pomija to wiele istniejących możliwości HTTP, takich jak uwierzytelnianie, buforowanie i negocjowanie typów zawartości, i może pozostawić projektantowi aplikacji ponowne wymyślenie wielu z tych funkcji w nowym słowniku.

Rzeczywiste obiekty, z którymi pracujesz, mogą mieć dowolny format. Chodzi o to, aby ponownie wykorzystać jak najwięcej HTTP, aby ujawnić operacje, które użytkownik chce wykonać na tych zasobach (zapytania, zarządzanie stanem / mutacja, usuwanie).

Zapytałeś :

Czy coś mi brakuje?

Jest dużo więcej informacji o REST i samych czasownikach URI / HTTP. Na przykład niektóre czasowniki są idempotentne, inne nie. Nie widziałem nic na ten temat w twoim pytaniu, więc nie próbowałem się w to zagłębiać. Pozostałe odpowiedzi i Wikipedia zawierają wiele dobrych informacji.

Ponadto można się wiele dowiedzieć o różnych technologiach sieciowych zbudowanych na podstawie protokołu HTTP, z których można skorzystać, jeśli używasz naprawdę spokojnego interfejsu API. Zacząłbym od uwierzytelnienia.

W odniesieniu do używania rozszerzenia do definiowania typu danych. Zauważyłem, że MailChimp API to robi, ale nie sądzę, żeby to był dobry pomysł.

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

Wydaje mi się, że to dobry pomysł, ale myślę, że „starsze” podejście jest lepsze - użycie nagłówków HTTP

GET /xxx/cars/1
Accept: application/json

Również nagłówki HTTP są znacznie lepsze do komunikacji między typami danych (jeśli kiedykolwiek ktoś by ich potrzebował)

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  

Czy coś mi brakuje?

Tak. ;-)

Zjawisko to występuje z powodu jednolitego ograniczenia interfejsu . REST lubi wykorzystywać już istniejące standardy zamiast wymyślać koło na nowo. Standard HTTP już okazał się wysoce skalowalny (sieć działa już jakiś czas). Po co naprawiać coś, co nie jest zepsute ?!

Uwaga: Jednolite ograniczenie interfejsu jest ważne, jeśli chcesz oddzielić klientów od usługi. Jest to podobne do definiowania interfejsów dla klas, aby oddzielić je od siebie. Ofc. tutaj jednolity interfejs składa się ze standardów, takich jak HTTP , typy MIME , URI , RDF , połączone słowniki danych , hydra vocab itp.

Dobra semantyka jest ważna w programowaniu.

Wykorzystanie większej liczby metod poza GET / POST będzie pomocne, ponieważ zwiększy czytelność kodu i ułatwi jego utrzymanie.

Czemu?

Ponieważ wiesz, że GET pobierze dane z Twojego interfejsu API. Wiesz, że POST doda nowe dane do twojego systemu. Wiesz, że PUT dokona aktualizacji. DELETE usunie wiersze itp.,

Zwykle strukturyzuję moje RESTFUL Web Services tak, że mam wywołanie zwrotne funkcji o tej samej nazwie, co metoda.

Używam PHP, więc używam function_exists (myślę, że to się nazywa). Jeśli funkcja nie istnieje, rzucam 405 (METODA NIEDOZWOLONA).

Bill Venners: W swoim poście na blogu zatytułowanym „Why REST Failed” powiedziałeś, że potrzebujemy wszystkich czterech czasowników HTTP - GET, POST, PUT i DELETE - i narzekałeś, że dostawcy przeglądarek tylko GET i POST. „Dlaczego potrzebujemy wszystkich czterech czasowniki? Dlaczego nie wystarczy GET i POST?

Elliotte Rusty Harold: Istnieją cztery podstawowe metody HTTP: GET, POST, PUT i DELETE. GET jest używany przez większość czasu. Służy do wszystkiego, co jest bezpieczne, co nie powoduje żadnych skutków ubocznych. GET może być dodawany do zakładek, zapisywany w pamięci podręcznej, powiązany z serwerem proxy. To bardzo potężna operacja, bardzo użyteczna operacja.

Natomiast POST jest prawdopodobnie najpotężniejszą operacją. To może zrobić wszystko. Nie ma ograniczeń co do tego, co może się wydarzyć, dlatego trzeba z tym bardzo uważać. Nie dodajesz tego do zakładek. Nie buforujesz tego. Nie pobierasz go z wyprzedzeniem. Nie robisz nic z POST bez pytania użytkownika. Chcesz to zrobić? Jeśli użytkownik naciśnie przycisk, możesz opublikować niektóre treści. Ale nie będziesz patrzeć na wszystkie przyciski na stronie i zacząć je losowo naciskać. Z drugiej strony przeglądarki mogą przeglądać wszystkie linki na stronie i pobierać je z wyprzedzeniem lub pobierać z wyprzedzeniem te, które według nich są najbardziej prawdopodobne, aby były śledzone jako następne. W rzeczywistości niektóre przeglądarki i rozszerzenia Firefoksa oraz różne inne narzędzia próbowały to zrobić w takim czy innym momencie.

PUT i DELETE znajdują się pośrodku między GET i POST. Różnica między PUT lub DELETE i POST polega na tym, że PUT i DELETE są * idempotentne, a POST nie. W razie potrzeby można powtórzyć PUT i DELETE. Załóżmy, że próbujesz przesłać nową stronę do witryny. Załóżmy, że chcesz utworzyć nową stronę pod adresem adresem http://www.example.com/foo.html, więc wpisujesz treść i PUTUJESZ ją pod tym adresem URL. Serwer tworzy tę stronę pod podanym adresem URL. Teraz załóżmy, że z jakiegoś powodu twoje połączenie sieciowe przestaje działać. Nie jesteś pewien, czy prośba została przesłana, czy nie? Może sieć działa wolno. Może wystąpił problem z serwerem proxy. Tak więc można spróbować ponownie lub jeszcze raz - tyle razy, ile chcesz. Ponieważ PODAWANIE tego samego dokumentu pod ten sam adres URL dziesięć razy nie różni się niczym od umieszczenia go raz. To samo dotyczy DELETE. Możesz USUNĄĆ coś dziesięć razy i to tak samo, jak jednorazowe usunięcie.

Z kolei POST może powodować za każdym razem coś innego. Wyobraź sobie, że wychodzisz ze sklepu internetowego, naciskając przycisk Kup. Jeśli ponownie wyślesz żądanie POST, możesz po raz drugi kupić wszystko w koszyku. Jeśli wyślesz go ponownie, kupiłeś go po raz trzeci. Dlatego przeglądarki muszą bardzo uważać na powtarzanie operacji POST bez wyraźnej zgody użytkownika, ponieważ POST może spowodować dwie rzeczy, jeśli zrobisz to dwa razy, trzy rzeczy, jeśli zrobisz to trzy razy. W przypadku PUT i DELETE istnieje duża różnica między zerowymi żądaniami a jednym, ale nie ma różnicy między jednym żądaniem a dziesięcioma.

Więcej informacji można znaleźć pod adresem URL. http://www.artima.com/lejava/articles/why_put_and_delete.html

Aktualizacja:

Metody idempotentne Metoda idempotentna HTTP to metoda HTTP, która może być wywoływana wiele razy bez różnych wyników. Nie ma znaczenia, czy metoda jest wywoływana tylko raz, czy dziesięć razy. Wynik powinien być taki sam. Ponownie dotyczy to tylko wyniku, a nie samego zasobu. Nadal można nim manipulować (jak znacznik czasu aktualizacji, pod warunkiem, że te informacje nie są udostępniane w (bieżącej) reprezentacji zasobów.

Rozważ następujące przykłady:

a = 4;

a ++;

Pierwszy przykład jest idempotentny: bez względu na to, ile razy wykonamy tę instrukcję, a zawsze będzie równe 4. Drugi przykład nie jest idempotentny. Wykonanie tego 10 razy da inny wynik niż wykonanie 5 razy. Ponieważ oba przykłady zmieniają wartość a, obie nie są metodami bezpiecznymi.

Zasadniczo REST to ( wiki ):

1. Architektura klient-serwer
2. Bezpaństwowość
3. Cacheability
4. System warstwowy
5. Kod na żądanie (opcjonalnie)
6. Jednolity interfejs

REST to nie protokół, to zasady. Różne metody i metody - ktoś tak zwane najlepsze praktyki.