web-dev-qa-db-ja.com

/ actionエンドポイントのRESTFulness

私は良いREST APIの例を見てきました。そして RackspaceのクラウドサーバーAPI がAWSのRPCのようなEC2 APIと比較してしばしば引用されることを読みました。

ただし、APIが次のようにサーバーを再起動することも確認しました。

POST /servers/{server_id}/action

{
    "reboot" :
    {
        "type" : "HARD"
    }
}

これは特定のシナリオでは理にかなっていますが、新しいリソースを投稿するようなものではなく、オブジェクトのメソッドを呼び出すようなものです。

server = Server(id)
server.reboot("HARD")

Restful Objectsの仕様 など、他の場所でも同様のことを見てきました。そこ、 GET /servers/{server_id}/actions/rebootは、アクションとそのパラメーターの説明、およびPOST/servers/{server_id}/actions/reboot/invokeは実際にアクションを呼び出します。

この方法で（「メソッド」とデータを含むリソース、OOPのような）リソースはRESTfulとしてカウントされますか？そして、そうでない場合でも、RESTこの種類の設計に従うAPIで失われたとされる利点のいずれかですか？

restapiapi-design
7
samfrances

これは特定のシナリオでは理にかなっていますが、新しいリソースを投稿するようなものではなく、オブジェクトのメソッドを呼び出すようなものです。

RFC 7231 4.3.

POSTメソッドは、リソースに固有のセマンティクスに従って、要求に含まれる表現をターゲットリソースが処理することを要求します。

要するに、HTTPリソースの統一インターフェースでは、POSTがキャッチオールです。他のどのメソッドもより適切でない場合は、POSTを使用します。

（HTMLメディアタイプがGETとPOSTのみを提供している場合でも、Webは見事に成功していることを常に心に留めておいてください）。

この方法（「メソッド」とデータを含むリソース、OOPなど））はRESTfulと見なされますか？

クライアントは、その方法を使用して、そのメッセージ本文をそのエンドポイントに送信することをどのようにして知っていますか？ REST=の主要なアイデアの1つは、その知識の通信が発生するということですインバンド;クライアントはそのエンドポイントにメッセージを送信することを知っていますアプリケーションの状態の表現サーバーから提供されたものです。

つまり： hypermedia 。

言い換えれば、Webでこれを行う方法を考えてください。ブックマークをロードすると、意味論的に注釈が付けられた一連のリンクを含む表現が返されます。シャットダウンサーバーリンクをたどると、必要なサーバーを選択できるように、フォームを含む表現が返されることがあります。これにより、使用可能なアクションが表示されます。これには、再起動アクションを実行するためのリンクが含まれています。そのリンクをたどると、再起動のタイプを指定できるフォームが表示されます。そのフォームを送信すると、システムを再起動するためのメッセージが処理されます。

ここでの重要なアイデアは、最初のブックマークを除いて、URIを知る必要はまったくなく、ブックマークを除いて、使用する統一インターフェースのメソッドを知る必要もないということです。配管の残りの部分はすべて、サーバーが提供する表現に由来します。

クライアント（ブラウザ）は、表現のメディアタイプを知る必要がありました。リンクとメソッドを説明するデータを見つけ、提供するセマンティックデータを見つける。プロトコルをたどるには、セマンティクス（再起動とはどういう意味ですか）に精通している必要がありますが、配管について何も知る必要はありませんでした。

フィールディング、 2008年に執筆

また、上記はまだ完全にRESTfulではないことにも注意してください。少なくとも私がこの用語をどのように使用しているか。私がやったことはすべて、RPCにすぎないサービスインターフェースについての説明です。 RESTfulにするために、サービスを導入して定義するハイパーテキストを追加し、フォームやリンクテンプレートを使用してマッピングを実行する方法を説明し、視覚化を便利な方法で組み合わせるコードを提供する必要があります。さらに進んで、Atomが通常のHTTP関係のセットを期待されるセマンティクスで標準化したように、これらの関係を標準として定義することもできます。..

つまり、エンドポイントだけでなく、それを見つけるまでの道のりでもあります。

この方法（「メソッド」とデータを含むリソース、OOPなど））はRESTfulとしてカウントされますか？

したがって、このAPIの具体的な例を使用して、いいえ、それはRESTfulとしてカウントされないことを主張します。応答がapplication/json（リンクの標準を定義しないメディアタイプ）であるという事実は、大きな警告の兆候です。さらに、交換された表現内ではなく、ホストに送信するメッセージ本文に関するすべての情報がout of bandで記述されているようです。

そして、そうでなくても、この種の設計に従うAPIでRESTの利点と考えられるものは失われますか？

失われる主なものは、統一されたインターフェイスで使用されるリソース識別子とメソッドを変更する機能です。たとえば、HTMLでは、表現を適切に変更するだけで、フォームをGETからPOST（またはその逆）に切り替えることができます。クライアントがハイパーメディアで表されているリンクをたどっているだけです。

たとえば、 Wayback Machineworks;スパイダーは、APIの安全なエンドポイントをクロールして（リンクの表現を見るだけでクロールするために safe であることがわかります）、データを収集しますすべてを置き換えますリソース識別子で、結果を利用できるようにします。クライアントは、正しい開始点が提供されると、元のAPIのリンクと同じように簡単にウェイバックマシンのリンクをたどることができます。

非常に簡単にこれをPOST/servers/{server_id}/actions/reboot/invocationsに変更できますが、少しチートのように感じられます。

RESTは、識別子に使用するスペルを気にしません。それらは不透明です。それらにエンコードされた意味は、サーバーの裁量で独自に使用するために行われます。

RESTに関する限り、次のリクエスト行はサーバーを再起動するリソースと完全に一致しています

POST /5dc2a243-f00b-40df-84b2-dbed81d73331 HTTP/1.1

この種のパターンがAPI全体で繰り返された場合、これによりRESTfulになります。

はい

名詞/物/リソースではなく動詞、プロセス、またはアクションを記述しているように見えるエンドポイントがある場合でも

はい。

URIの設計は、RESTとはまったく別の問題です。

5
VoiceOfUnreason

RESTfulのRは代表を意味します。代表者は具体的な便利なアイテムであるため、ステートフル（RESTfulのS）である代表者について話しています。 The rebootは、実質的なもの（代表者には大丈夫です）または動詞（代表者には大丈夫ではありませんが、RPCには大丈夫です）です。 invokeは、動詞の主要な例であり、RPCの場合は問題ありませんが、RESTfulの場合は問題ありません！

リクエスト

上手、 POST /servers/{server_id}/actionは、サーバーごとに一度に1つのアクションしかないと私に見えます。reboot、shutdownやstartupのような同期ジョブでは何が問題ないのでしょうか。

RPCはJITを意味することが多く、RESTfulはneverがJITを意味するため、RESTfulとRPCの時間を比較することはできません。

0
Peter Rader