web-dev-qa-db-ja.com

REST API-サブリソースの処理

プロフィール（名前、国別ID、DOB）、住所、連絡先（メール、電話）を持つプライマリリソース "/ accounts"があるとします。アカウントなしでは存在できないので、サブリソースとして考えています。それらを更新するには、2つのオプションを考えています

オプション1

  • PUT/accounts/{accountid}/address
  • PUT/accounts/{accountid}/contacts
  • PUT/accounts/{accountid}/profile

オプション2

  • PUT/accounts/{accountid}
    （アドレス/電話/プロファイルの存在/不在に応じて、実行する更新を決定します）

実装の観点から見ると、各更新には独自のロジックとプロセスフローがあるため、オプション1を使用したくなります。別のURIにより、実装をよりクリーンで管理しやすい状態に保つことができます

  1. プロファイル、住所、連絡先をサブリソースと見なすのは誤りでしょうか。もしそうなら、それらを表す適切な方法は何でしょうか
  2. 上記のうち適切なオプションであるか、検討すべき完全に異なるオプションがあるサブリソースと見なすことができる場合
restapiapi-design
7
sbhas

プロファイル、住所、連絡先をサブリソースと見なすのは誤りでしょうか。

いいえ、好きなものをサブリソースにすることができます。 RESTは関係ありません（サブリソースはリソースです）。パスを使用することは、階層要素の適切なURI設計です。

考慮すべき完全に異なるオプションはありますか？

しかし、より細かいリソースに向けた編集が必要な場合もあります。 PUTメソッドは、べき等の編集に最適です。これは部分的な編集には少し厄介です-公式には、http仕様は「PUTメソッドがOriginサーバーの状態にどのように影響するかを定義していません」。しかし、putには、作成または置換のセマンティクスを使用して、リソースの完全な表現を含めることになっていることは広く理解されています。

たとえば、常にプロファイルの3つのフィールドすべてを同時に編集する場合は、単一のリソースを使用してロットを変更するのが適切です。一方、他のフィールドを気にせずに生年月日の置き換えをサポートしたい場合、専用のサブリソース（例：/ accounts/{accountId}/profile/dob）に変更を書き込むと、驚く人が少なくなります。 ）。

これは一般的な問題です。直接変更してリソースを更新するか、サブリソースを変更してリソースに変更を加えますか。たとえば、定義に複数の連絡先があるようです-連絡先への編集を直接受け入れるのが適切な場合があります。あるいは、連絡先の表現が、代わりに連絡先/メールまたは連絡先/電話で実行された編集を反映している場合があります。 。

4
VoiceOfUnreason

HTTPおよびRESTリソースが「サブリソース」であるかどうかは関係ありません。「なしでは存在できない」制約に関する構造的な知識はありません。

一貫性の観点から、PUTが「サブリソース」に許可されている場合、少なくとも親リソースとは別にGETもできると期待します。次に、厳密な レベル RESTアプローチ（HATEOAS）は、アドレスリソースへのハイパーメディアリンクをGET Accountの応答に含めることをお勧めします。そこに住所データを直接含めます。

1
guillaume31