1

オブジェクト グラフを作成するための RESTful API を設計する方法に頭を悩ませようとしています。たとえば、リソースが次の関係を持つ eCommerce API について考えてみます。

オーダー（メインオブジェクト）

  • 多数のアドレス
  • Has-many Order Line items (注文の構成要素)
  • 多額の支払い
  • 連絡先情報が多い

Order リソースは、通常、その関連付けとともに意味があります。単独では、ビジネス上の重要性を持たない単なるコンテナです。ただし、関連付けられた各オブジェクトには独自の寿命があり、独立して操作する必要がある場合があります。注文の配送先住所の編集、注文に対する連絡先情報の変更、発注後の注文からの項目の削除など。

API の設計には 2 つのオプションがあります。

  • Order API エンドポイントは、送信されたコンテンツ内の「ネストされたリソース」を処理することにより、自身とそれに関連付けられたリソースをインテリジェントに作成します。POST /orders
  • Order リソースはそれ自体を作成するだけであり、クライアントは、 などPOST /orders/123/addressesの新しく作成されたエンドポイントに対してフォローアップの POST リクエストを行う必要があります。PUT /orders/123/line-items/987

2 番目のオプションはサーバー側での実装がより簡単ですが、ユースケースの 80% でクライアントが余分な作業を行う必要があります。

最初のオプションには、次の未解決の問題があります。

  • 新しく作成されたリソースの URL をどのように伝えるのでしょうか? ヘッダーは 1 つのLocationURL しか通信できませんが、サーバーは複数のリソースを作成する可能性があります。
  • エラーにどのように対処しますか？アソシエーションの 1 つにエラーがある場合はどうなりますか? オブジェクトグラフ全体を拒否しますか? そのエラーはどのようにクライアントに伝えられますか?

これに対処するRESTful +実用的な方法は何ですか?

4

2 に答える 2

1

これをどのように処理するかが最初の方法です。クライアントが必要なすべての要求を行うと想定しないでください。1 つの要求ですべてのエンティティを作成します。

ユース ケースによっては、エンティティを作成する際に「オール オア ナッシング」アプローチを適用することもできます。つまり、何かが落ちると、すべてが元に戻ります。これは、データベースでトランザクションを使用することで実行できます (すべてが個別の要求によって行われる場合も、これは実行できません)。これが必要な動作であるかどうかを判断することは、状況に非常に固有です。たとえば、注文明細書を作成している場合は、これを使用することができます (欠品のある注文を作成したくない場合)。ただし、写真をアップロードしている場合は問題ありません。

クライアントにリンクを返すために、私は常に JSON オブジェクトを返します。このオブジェクトには、作成された各リソースへのリンクを簡単に設定できます。このようにして、クライアントは投稿が成功した後の動作を決定できます。

于 2013-03-12T00:20:20.497 に答える
0

どちらのオプションも RESTful に実装できます。あなたが尋ねる：

新しく作成されたリソースの URL をどのように伝えるのでしょうか? ヘッダーは 1 つのLocationURL しか通信できませんが、サーバーは複数のリソースを作成する可能性があります。

linksこれは、この場合、他のリソースに s を伝えるのと同じ方法で行われますGET。linkリソースの URL を表現に埋め込むには、要素または任意の方法を使用します。

于 2013-03-11T09:07:27.303 に答える