"関連する"リソースのRESTデザイン

Question

複数のアカウントを持つ顧客があるとします。実際には、他の複雑なオブジェクトと "1対多の"関係を持つデータオブジェクトはすべて行います。

例は次のようになります。

{ id: 1, name: "Bob", accounts: [ { id: 2, name: "Work account" }, { id: 3, name: "Home account" } }

私の質問は、それがが顧客のサブリソースとして、対独立したリソースとしてを占めて公開するために、より良い/適切な場合、ありますか？または両方？

たとえば、私の最初の直感は、次のようになります。/customers/1上記のオブジェクトを返します。いずれかのアカウントを変更する場合は、POST〜/accounts/2にする必要があります。

（私はいくつかのAPIで見てきた）、それについて移動する他の方法は、上記の配列を返す別のルート/customers/1/accountsを公開することであり、その後、APIのユーザーはの配列を変異させることができるようにそこにPOST/PATCHルートを設定しますアカウント。

そのアプローチと私の問題は、アカウントの配列は、実際には「参照によって含まれる」されている場合、それはRESTルートはアカウントを変更しているか、それは単に顧客との間でリンケージを変更するかどうかを実際に明確ではないということですアカウント。

ここにベストプラクティスがありますか？

Answer 1

これは良い質問であり、議論の対象となっています（「正しい」回答はありません）。お客様のリソースに埋め込まれた子アカウントのリソースを持つ

1. より多くのデータが常に/顧客/ {ID}の要求で送り返されることになります。ここではいくつかのあなたは検討する必要があります点です。

2. 基本的な顧客情報とアカウント情報の両方が必要な場合は、子アカウントリソースが埋め込まれていないと、クライアントは複数のHTTP要求を送信する必要があります。

3. セキュリティパラダイムが埋め込みリソースでどのように機能するかを正確に判断したいと思うでしょう。 （つまり、顧客の情報を取得することは可能ですが、顧客のアカウントを見ることはできませんか？）

4. お客様のドメインにアカウントを持たないのは理にかなっていますか？アカウントは所有権を譲渡できますか？そうでなければ、/ customers/{id}/accounts/{acct_id}が理にかなっています。デフォルトでは、あなたは常に顧客と口座間の連携のアカウントを変更していないので、RESTの定義に暗黙

、URIにHTTPメソッドを発行することは、URIで識別されるリソースを変更しています。

、アカウントのリンクを変更する機能を必要とする場合は、リソースのように、「アカウントのリンク要求」（POST /アカウント/ {ID}/linkreqeustまたはその自然の何か）を発明することができます。この要求には、要求を評価するバックエンド機能があり、次に顧客との間でアカウントをリンクまたは切り離してから、アタッチ/デタッチ処理を行うかどうかを判断する独自の状態があります。

要約すると、異なるリンク（/ accounts/{id};/customers/{id}/accounts/{acct_id}）を持つ同じリソースを参照できないRESTには何もありません。私の好みは、サブリソースを持つことへのセキュリティの影響がない場合、それをサブリソースに単独でアクセスするためのエンドポイントと一緒に持つことです。アカウントが複数のユーザーに結びついている（または顧客がいない）場合は、/ accounts/{id}エンドポイントも公開します。

すでに疑われたよう

ex. /customers/1: 

{ 
    "id": "1", 
    "name": "John Doe", 
    "accounts": { 
    "collection": [ 
     { 
     "id": "1", 
     "type": "savings", 
     "balance": "$400", 
     "links": { 
      "self": "/customers/1/accounts/1" 
     } 
     }, 
     { 
     "id": "2", 
     "type": "checking", 
     "balance": "$600", 
     "links": { 
      "self": "/customers/1/accounts/2", 
      "detach" : "/customers/1/accounts/2/linkrequest?action=detach" 
     } 
     } 
    ], 
    "links": { 
     "self": "/customers/1/accounts", 
     "attach": "customers/1/accounts/linkrequest?action=attach" 
    } 
    }, 
    "links": { 
    "self": "/customers/1" 
    } 
} 

Answer 2

、それはすべて、データベース内のデータ表現モデルに降りてくるのです。所有関係（実際のエンティティリスト）、所有されていない関係（「参照によって含まれる」と呼ばれるもの）、またはバックリンク参照（アカウントの顧客バックリンクフィールド）による暗黙的な1：N関係です。 GETでデータを取得するために、次のように表現モデルに応じて使用することができる

：

/customers/1/accounts 
/accounts?customer eq 1