Operacje inne niż CRUD w usłudze RESTful

Jaki jest „RESTful” sposób dodawania operacji innych niż CRUD do usługi RESTful? Powiedzmy, że mam usługę, która umożliwia CRUD dostęp do takich rekordów:

GET /api/car/123           <- Returns information for the Car object with ID 123
POST /api/car              <- Creates a new car (with properties in the request)
PUT /api/car/123           <- Updates car 123 (with properties in the request)
DELETE /api/car/123        <- Deletes car 123    
POST /api/car/123/wheel/   <- Creates a wheel and associates it to car 123

Gdybym chciał zmienić kolor auta, po prostu POST /api/car/123dodałbym zmienną POST dla nowego koloru.

Ale powiedzmy, że chcę kupić samochód, a ta operacja jest bardziej skomplikowana niż zwykła aktualizacja właściwości „posiadanego samochodu” w rekordzie „użytkownika”. Czy RESTful jest po prostu zrobić coś takiego POST /api/car/123/purchase, gdzie „zakup” jest w istocie nazwą metody? A może powinienem użyć niestandardowego czasownika HTTP, na przykład PURCHASEzamiast POST?

A może operacje inne niż CRUD są całkowicie poza zakresem REST?

Pomyśl o zakupie jak o jednostce biznesowej lub zasobie w słowniku RESTful. Biorąc to pod uwagę, dokonanie zakupu w rzeczywistości tworzy nowy zasób. Więc:

POST /api/purchase

złoży nowe zamówienie. Szczegóły (użytkownik, samochód itp.) Powinny być przywoływane przez id (lub URI) w treści przesyłanej na ten adres.

Nie ma znaczenia, że ​​zamówienie samochodu to nie tylko zwykłe WSTAWIENIE w bazie danych. W rzeczywistości REST nie polega na ujawnianiu tabel bazy danych jako operacji CRUD. Z logicznego punktu widzenia tworzysz zamówienie (zakup), ale strona serwera może wykonać dowolną liczbę kroków przetwarzania.

Możesz nawet dalej nadużywać protokołu HTTP. Użyj Locationnagłówka, aby zwrócić link do nowo utworzonego zamówienia, uważnie wybierz kody odpowiedzi HTTP, aby poinformować użytkowników o problemach (po stronie serwera lub klienta) itp.

REST, jak rozumiem, polega na tym, że nie potrzebujesz nowych czasowników HTTP, gdzieś jest rzeczownik, który będzie oznaczał to, co musisz zrobić.

Kupujesz samochód? Cóż, nie jest to

POST /api/order

To, co naprawdę robisz, to tworzenie zamówienia. Więc dodaj kolejny zasób do zamówienia i opublikuj i umieść tam podczas procesu zamówienia.

Myśl w kategoriach zasobów, a nie wywołań metod.

Aby sfinalizować zamówienie, prawdopodobnie POST / api / order // ukończone lub coś podobnego.

Uważam, że interfejsy API REST pomagają na wiele więcej sposobów niż tylko zapewnianie semantyki. Nie można więc wybrać stylu RPC tylko z powodu niektórych wywołań, które wydają się mieć większy sens w stylu obsługi RPC. Przykładem jest interfejs API map Google do znajdowania wskazówek między dwoma miejscami. Wygląda tak: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

Mogli nazwać to „findDirections” (czasownik) i potraktować jako operację. Zamiast tego uczynili „kierunek” (rzeczownik) jako zasób i traktowali znajdowanie kierunków jako zapytanie o zasób kierunków (chociaż wewnętrznie nie może istnieć żaden prawdziwy zasób zwany kierunkiem i można go zaimplementować w logice biznesowej, aby znaleźć kierunki na podstawie parametrów).