web-dev-qa-db-ja.com

RESTでのエンティティ関係の作成：子IDに投稿して親を作成できますか？

現在、REST APIを設計して従来の顧客データにアクセスします。APIの要素の1つはユーザーのアセットです。アセットは特定のサービスの下に追加されます。バックエンドAPIは特定のサービスの下でユーザーにアセットを追加します。したがって、User--Asset関係はありませんが、User-[Service]-Asset関係があります。

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

/users/{id}/assets/{id}/services/{id}

APIを使用すると、アセットIDとサービスIDがわかり、新しいエントリが作成されます。私たちが苦労しているのは、この関係の創造です。

簡単な方法の1つは、/users/{id}/assets/への関係全体を投稿することです。

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

しかし、URIが示すように実際にアセットを作成するのではなく、アセットとサービスの関係を作成します。

別の方法として、次のように関係をアドレス指定するURIにPOSTすることを検討しています。

POST /users/{id}/assets/{id}/service/{id}
{attribute1:"{var}", attribute2:"{var}"}

ただし、この場合、リソースパス/users/{id}/assets/{id}はPOSTの前に存在せず、副作用として作成されます。

存在しないリソースパスへのPOSTはまったく許可されていますか？

あなたの考えをありがとう、

ジェラール。

designdesign-patternsrest
9
maasg

ユーザーが存在しない関係に最初に投稿するときはいつでも、投稿の一部として作成することをお勧めしているようです。

この種のオンアクセス作成パターンが有効で許容可能な開発パターンであるかどうかを尋ねている場合、答えは「はい」です。これは有効であり、かなり一般的なパターンです。

3
blueberryfields

ここに複数のポイントがあります：最初：新しいIDがすでに存在している可能性があるため、または新しいリソースを作成するときにIDを入力しないでください。生成されたIDでフィードバックを取得するには、作成リソースの場合、ロケーションヘッダー属性をシステムで設定する必要があることをシステムが作成する必要があることを提案します。

2番目：JSONが正しくありません。リソースURIサービス「s」と同様に、アセットオブジェクト内の別のオブジェクトとしてサービスを処理する必要があります。配列として処理する必要があります。

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

である必要があります：

POST /users/{id}/assets    
{services:[{ attribute1:"var", attribute2:"var"}]}

この方法で使用する場合

第三に、私はこの方法を設計提案に使用することを好みません。このケースが失敗した場合、アセットまたはサービスの作成中に失敗したことをどのようにして知ることができますか。

2
Bassem Reda Zohdy

これは別の考え方です：

POST /relationships
{ relationship:${id}, asset:{id}, service:{id}, user:{id}, data:"some data" }

このようにして、関係をアセット、サービス、ユーザー間の3方向リンクとして定義し、階層関係を意味しません。

その後、次の方法で特定の関係を取得できます。

GET /relationships?id="2144321"

または、次の方法で関係のサブセットを検索します。

GET /relationships?user="43434"

または

GET /relationships?asset="12433"

元の方法は間違っていませんが、このアプローチにより、誰が使用するかをより柔軟に指定できる場合があります。

0
Michael Shaw