5

私はRESTfulアーキテクチャの信条をかなりよく理解していると思いますが、まだそこにはいません。

私が理解できない部分は、クライアントが各リソースで使用可能なHTTPメソッドをどのように認識できるかということです。プロセスを続行するためにアプリケーションフローで特定のアクションが必要な場合はどうでしょうか。

簡略化した例：

クライアントがRESTAPIに簡単な注文をしたと仮定します。

クライアントは、http：//api.mycompany.com/ordersに投稿リクエストを行います。

ペイロードのリクエスト

<order>
    <items>
        <sku>12345</sku>
        <quantity>1</quantity>
    </items>
</order>

リクエストが成功したと仮定します

応答ペイロード

<order>
    <id>156</id>
    <status>Pending Payment</status>
    <items>
        <sku>12345</sku>
        <quantity>1</quantity>
    </items>    
    <links>
        <link rel="order" url="http://api.mycompany.com/orders/156" />
        <link rel="invoice" url="http://api.mycompany.com/payments/156" />
        <link rel="payment" url="http://api.mycompany.com/invoices/156" />
    </links>
</order>

ハイパーメディアの制約を正しく理解していれば、対応するリソースを提供し、クライアントはそこからどこに行くかを選択できます。

上記の例では、rel = "order"のリンクは、GET、PUT、またはDELETEリクエストである可能性があります。rel = "invoice"のリンクは、GETリクエストに制限されています。rel = "payment"のリンクは、 POSTリクエストのみを受け入れます。

クライアントはこれをどのように知っていますか？前述のリソースの1つにOPTIONSリクエストを送信すると、使用可能なメソッドが提供されるはずですが、それがこの種のシナリオを処理する標準的な方法であるかどうかはわかりません。

どんな助けでも大歓迎です。

4

2 に答える 2

6

単純な事実として、これらの動詞はリソースのドキュメントに記載されます。

あなたが尋ねなかった質問は、「クライアントは、refs 'order'、'invoice'、および 'payment' が何のためにあるのかをどうやって知るのですか?」です。

それでも、彼らはあなたが求めているのと同じ問題に苦しんでいます。また、それらも文書化する必要があります。

それらが文書化され、それらが何であるか、なぜそれらが存在するのか、そしてリソース消費者としてのあなたがそれらを何のために使用するのかについて説明されるとき、それらのリソースを活用するために必要な実際の動詞もそれらと共に文書化されます.

于 2011-06-02T20:11:41.443 に答える
0

クライアントは、公開した任意の URI で任意の HTTP 動詞を呼び出すことができます。それらの行動が何らかの効果をもたらすかどうかは別の問題です。

クライアントは、特定の URI でどのメソッドがさまざまな方法で機能するかを発見できます。

  1. さまざまなアクションで各 URI を呼び出し、どの URI が機能し (2xx 応答コードを返す)、どの URI が を返すかを動的に判断します405 - Method Not Allowed。
  2. クライアント プログラマーはドキュメントを読み、対話を前もってコード化します。

正直に言うと、#1 が実稼働システムに実装されているのを見たことがありません。#2 は、REST API を使用するクライアントを作成する必要がある私とほとんどの人にとって最も理にかなっていることです。

REST API を使用することは、使用する HTTP 動詞を知るだけではないことに注意してください。メディア タイプのコンテンツと構造 (要求と応答の両方) は、文書化して、システムに対してコーディングを計画している人々が利用できるようにすることが重要です。

于 2011-06-02T20:18:39.837 に答える