REST APIでの複雑なアクションの命名

RESTの説明にあるすべてのマニュアルでは、ユーザーなどの単純な例を示しています。/usersリソースになります。ここに1人のユーザーがいます。/users/[id]で、アクションを追加/削除/変更します。

しかし、アクションが複雑または複雑で、GET \ POST \ DELETEに適合しない場合はどうでしょうか？



それを理解しようとして、彼はトースターで質問をし、さらに発掘を続けました。
網羅的な記事を見つけましたが、完全な翻訳を処理することはできませんので、短いメモで結論を要約します。

問題について簡単に説明します。

RESTとRPCの主な違いは、URLがリソースのアドレスであり、標準のHTTPメソッドを使用して実行されるアクションであるというアプローチです：GET \ POST \ DELETE \ PATCH \ ...要するに、リソースは動詞ではなく名詞です。

つまり / api / users / do_some_cool_staffまたはGET / users / 1？のようなものが表示された場合、action = delete、わかっています-これはRESTではありません！

RESTインターフェースを備えた核スーツケースアプリケーションを作成しているとします。 機能は次のとおりです。

1.ロケット[id]によるアクション：国での打ち上げ、国での販売、サービス、償却

リソース/ミサイル/ [id]を使用するのは論理的ですが、これらのアクションでは、PUTまたはPATCHを使用するだけでは不正確で情報量が多くなります。

間違ったオプション：
1.標準HTTPメソッドのリストを展開できます。 ただし、さまざまなクライアント、既製のライブラリ、およびフィルタリングサーバー設定のサポートには困難がある場合があります。
2. /ミサイル/ [id]？Action = launchは、RESTアプローチ全体を無意味にします。 ほとんどの機能はアクションにあります。
3. /ミサイル/ [id] / launch-動詞をリソースアドレスにドラッグするのは正しくありません。
4.リンク/ミサイル/ [id] /国/ [country_id] /-正確に何が起こっているのか明確ではありません-売却または核攻撃。

正しいオプション
リソースのプロパティに正しくアクセスします。 つまり アクション「/ users / [id] / disable」ではなく、リソース「/ users / [id] / disable d 」、標準メソッドGET \ POST \ ...

ロケット打ち上げ：POST /ミサイル/ [id] /国上陸/ [country_id]
ロケット販売：POST /国/ [country_id] /ミサイル購入/ [id]またはPOST /ミサイル/ [id] /所有者/ [country_id]
サービス：POST /ミサイル/ [id] /オンサービス
UPD：
ロケット打ち上げ：POST /ミサイル/ [id] /ランチャー{target：[country_id]}
ロケットセール：パッチ/ミサイル/ [id] {所有者：[country_id]}
サービス：PUT /ミサイル/ [id] /オンサービスまたは個別のミサイルサービスがある場合POST / missiles_service / {missile：[id]}
削除：DELETE /ミサイル/ [id]またはPUTを「削除」する他のオプションがある場合/ミサイル/ [id] /使用済み

2.国[country_id]で適切なロケットを発射します

ミサイルは非常に小型で、最初に検索を実行し、次にオーバーヘッドを起動すると仮定します。長時間実行するには、すぐに実行するために1つの要求が必要です。
間違ったオプション：
1.ミサイルのコレクション全体（「未知の特定のミサイルの[id]」）に対して「起動」を実行します。
2.選択した国からのアクション「ロケットをゲット」

正しいオプション
アクションが複雑で、リソースオブジェクトのアトミックアクションで表現できない場合、リソースプロセスが作成されます。 同様に、銀行取引など、複雑なビジネスロジック（複数の依存アクションで構成される）で複合アクションを実行する場合、リソースプロセスが作成されます。



つまり Rocket Launchリソースの作成は正しいものになります。
次に、POSTがロケットを起動し、GETがプロセスのステータスを認識し、DELETEがキャンセルします。 同時に、一貫性が維持されます。 ロケットはすでに飛行しており、国のステータスは「まだ存在しています」。

ボーナス：

多くの大企業はRESTが何であるかわからないことがわかり、この名前は説明で使用されています。 そのため、大規模な人々 であっても、フェンスに書かれているものすべてを信頼することはできません。

Achtungsの例：

• Twitter
  友情の投稿/作成
  友情をPOST /破壊する
  友情の投稿/更新
  友情を得る/ショー
  友達を取得/リスト
  
• Mail.ru
  すべてのAPIメソッド呼び出しは、特定のパラメーターセットを持つURL www.appsmail.ru/platform/apiへのGETまたはPOST HTTP要求です。 [...]現時点では、APIはGET要求とPOST要求を区別しません。
  

GitHubを発見できた唯一のまともなREST API。 アーメン