3

私は次のステートマシンを持っていて、これが欲しいです：

  1. 新しい注文を作成する
  2. アイテムを追加します（リストはオプションです）
  3. 終了を呼び出して注文を確認します
  4. それを支払う
  5. それを送る

そして、このフローはREST Webサービスを介して制御されており、どちらの方法がRESTの原則によく準拠しているかはわかりません。

ここに画像の説明を入力してください

私は2つの可能性を思いつきました（下の数字は上の数字に対応しています）：

最初のもの-操作はパスによって指定されます

1. 
POST /create HTTP/1.1

2. 
POST /addItem HTTP/1.1
<data>
    <itemId>123</itemId>
</data>

GET /listItems HTTP/1.1

3.
POST /finish HTTP/1.1

4. 
POST /pay HTTP/1.1
<data>
    <price>123</price>
</data>

5. 
POST /send HTTP/1.1

2番目のもの-操作は本文で指定されます

1. 
POST / HTTP/1.1
<data>
    <operation>create.new.order</operation>
</data>
- returns resId

2. 
PUT /{resId} HTTP/1.1
<data>
    <itemId>123</itemId>
</data>

GET /items HTTP/1.1

3.
PUT /{resId} HTTP/1.1
<data>
    <operation>finish.order</operation>
</data>

4. 
PUT /{resId} HTTP/1.1
<data>
    <price>123</price>
    <operation>pay.order</operation>
</data>

5. 
PUT /{resId} HTTP/1.1    
<data>
    <operation>send.order</operation>
</data>

2番目の解決策の方が良いようですが、リクエストの本文で操作を指定できるかどうかわかりません-大丈夫ですか？

また、リソースを実際に更新するのではなく、ステートマシンの状態を変更するだけなので、2番目のソリューションで使用するPUTか、それとも使用するかがわかりません。POST35

これらのどれも正しくない場合、どうすればよいですか？

4

1 に答える 1

3

どうですか：

POST /orders

そこから、作成されたばかりの注文のURLを指定201 Createdするヘッダーとともに応答が返されます。Content-Location/orders/2876276

次に、既存の注文にアイテムを追加します。

POST /orders / 2876276

メッセージには、注文に追加するものを指定する、URLエンコードされたフォームデータを含めることができます。

それで、

GET /orders / 2876276

...注文の表現を取得します。コンテンツタイプのネゴシエーションを実行して、json、xmlなどの形式にするかどうかを判断できます。応答メッセージは、リクエスターと共有したい注文に関するすべての情報を提供します。受領日、ステータス、注文アイテムなど。

正確にはわかりませんFINISHが、私の素朴な見方では、これは注文アイテムに対する特別な種類の更新であるため、特別なフォームデータを使用した別のPOSTです。終了したPOSTの後、aへの応答にはGET、注文が「完了」したことを示す特別なインジケーターが含まれます。

支払いを処理するには、同じ注文で別のPOSTを使用できます。設計で売掛金の追跡が必要な場合は、別のオブジェクトが完全に存在する可能性があります。つまり、注文ごとに1回の支払いがないが、顧客が毎月または他のリズムで請求される場合は、のような別のオブジェクトカテゴリがあります/accounts/39839。しかし、単純なケースでは、注文オブジェクトを使用して支払い状態を追跡することができます。

したがって、POST支払いを取得するためのクレジットカードまたはペイパル情報を提供する注文URLに。その後、GETは、支払われた注文を含む表現を取得します。

「送信」はHTTPリクエストではないと思います。送信は、支払いを受け取った後に注文を履行するために行うことです。おそらく、あなたの店のいくつかのシステムは、/orders/872872872それが送信されたことをマークするために投稿することができます。その後、GETは、おそらく追跡番号とともに、出荷された注文を含む表現を取得します。

の使用には注意が必要PUTです。PUTは、オブジェクト全体がリポジトリに挿入されていることを示し、オブジェクトがすでに存在する場合は暗黙的に置換されます。しかし、あなたのモデルはそれを要求していません。注文マネージャーは注文を管理し、各注文に対する限られた一連の操作（アイテムの作成、追加など）を公開します。注文全体の挿入は、これらの操作の1つではありません。したがって、PUTはシナリオでは間違っているように見えます。

ドキュメントをリポジトリに挿入する場合は、PUTが適切です。たとえば、商品を売りに出すオークションを想像してみてください。を使用POSTしてオークションアイテムを作成し、/items/29829アイテムのURLとして受け取ることができます。次に、PUTを使用して、オークションにかけられているアイテムに画像を追加することができます。PUT/items/29829/mainImageなどを使用できます。PUTは、PUTを実行しているもののURLを知っていることを意味します。

あなたが尋ねた：

リクエストの本文で操作を指定できるかどうかわかりません-大丈夫ですか？

HTTPには、制限された動詞のセットしかありません。「注文」オブジェクトにはさまざまな状態があります。HTTP動詞を状態遷移にマップする必要があります。状態遷移または状態変化ごとに、注文オブジェクトに対してPOSTを使用することは理にかなっています。これは、リクエストの本文で「操作」を指定していると考えるかもしれませんが、私にとっては、リクエストの本文でリクエストの詳細を指定しています。これはまさにリクエストボディの目的です。

詳細については、コーヒーを飲む方法をご覧ください。

于 2012-04-14T19:53:35.950 に答える