RESTfulサービスでの非CRUD操作

非CRUD操作をRESTfulサービスに追加する「RESTful」な方法は何ですか？次のようなレコードへのCRUDアクセスを許可するサービスがあるとします。

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

車の色を変更したい場合POST /api/car/123は、単純に新しい色のPOST変数を含めます。

しかし、車を購入したいとします。その操作は、単に「ユーザー」レコードの「所有車」プロパティを更新するよりも複雑です。POST /api/car/123/purchase「購入」が基本的にメソッド名であるのようなことを単純に行うのはRESTful ですか？または、PURCHASE代わりになどのカスタムHTTP動詞を使用する必要がありPOSTますか？

または、非CRUD操作は完全にRESTの範囲外ですか？

RESTful辞書のビジネスエンティティまたはリソースとして購入を考えてください。そうは言っても、実際に購入すると、新しいリソースが作成されます。そう：

POST /api/purchase

新規注文します。詳細（ユーザー、車など）は、このアドレスに送信されるコンテンツ内のID（またはURI）で参照する必要があります。

車の注文がデータベースの単なるINSERTではないことは問題ではありません。実際、RESTはデータベーステーブルをCRUD操作として公開することではありません。論理的な観点からは、注文（購入）を作成しますが、サーバー側は必要な数の処理ステップを自由に実行できます。

HTTPプロトコルをさらに悪用することもできます。Locationヘッダーを使用して、新しく作成された注文へのリンクを返し、HTTP応答コードを慎重に選択して、問題（サーバー側またはクライアント側）についてユーザーに通知します。

私が理解しているRESTfulな方法は、新しいHTTP動詞は必要ないということです。何をすべきかを意味する名詞がどこかにあります。

車を購入しますか？まあそれではない

POST /api/order

あなたが本当にやっていることは、注文を作成することです。したがって、注文用の別のリソースを追加して投稿し、注文プロセス中にそこに入れます。

メソッドの呼び出しではなく、リソースの観点から考えてください。

注文を確定するには、おそらくPOST / api / order // completeまたは同様の何かを行います。

REST APIは、セマンティクスを提供するだけでなく、はるかに多くの点で役立つと思います。したがって、RPC操作スタイルでより理にかなっているように見える呼び出しがあるからといって、RPCスタイルを選択することはできません。例は、2つの場所の間のルートを検索するgoogle maps apiです。次のようになります：http : //maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

彼らはそれを「findDirections」（動詞）と呼んで、操作として扱ったかもしれません。むしろ、彼らは「方向」（名詞）をリソースとして作成し、方向を見つけるリソースをクエリとして扱いました（内部的には、方向と呼ばれる実際のリソースはなく、ビジネスロジックによって実装され、パラメーターに基づいて方向を見つけることができます）。