2016-05-17 8 views
1

API parent - > childリソースを提供する一般的に受け入れられた方法があるかどうかを判断しようとしています。 Personエンティティがあり、各PersonにAddressエンティティが表す0以上のアドレスがあるとします。基本的なAPIの面ではparent - > child要素呼び出しのAPI規約

我々は持っていると思います:

  1. /api/v1/person/{id}/addresses
  2. /api/v1/addresses/{personId}

POST: /api/v1/person 
GET:  /api/v1/person/{id} 
PUT:  /api/v1/person/{id} 
DELETE: /api/v1/person/{id} 

はその後、我々は、人のアドレスを取得するための2つの方法があります

前者のオプションを選択するのがより自然だと感じていますGETのためにしかし同時に私たちがidによってアドレスを取得したい場合は/api/v1/address/{id}でなければなりません。

質問は、POST、PUT、DELETE呼び出しを扱う際の規約がありますか?私には、これらのアドレスサービスを/api/v1/address OR /api/v1/address/{id}という名前で呼び出す必要がありますが、同時に人IDを渡す代わりに誰かが `/ api/v1/person/{id}/address 'にPOSTする理由がわかりますリクエスト本体。

そうですね、あなたが正しい方向に私たちを指摘することができますか?親と子の関係に関しては、APIデザインには書かれたルールと書かれていないルールがありますか?

ありがとうございます!

答えて

1

人がいないと住所が存在しますか?答えが「はい」の場合、アドレスはそれ自身のリソースでなければなりません。

  • /api/v1/addresses:すべてのアドレスのコレクション
  • /api/v1/addresses/{addressId}:単一のアドレス
  • /api/v1/addresses?person={personId}:それはすぐに明らかにされていませんので、

人のためのすべてのアドレスが、私は/api/v1/addresses/{personId}を使用していないと思いますpersonIdは、アドレスではなく人のIDです。

しかし、同時に、/api/v1/person/{id}/addressesは、ある人から彼のすべてのアドレスに移動するために利用できる必要があります。

住所が人なしで存在できない場合は、/api/v1/person/{id}/addressesのみを使用してください。

+0

あなたの言っていることに完全に同意します。私が気づいていない隠れた慣習がないことを確認したい返信いただきありがとうございます! – RVP

関連する問題