私はサーバーサイド Web 開発の初心者で、最近は RESTful API の実装についてたくさん読んでいます。REST API でまだ行き詰まっている点の 1 つは、クライアントが対話できるリソースを識別する URI 階層をどのように構築するかということです。具体的には、階層をどの程度詳細にするか、リソースが他のリソース タイプで構成されている場合はどうするかを決めるのに困っています。
ここで、私が言いたいことを説明できる例を挙げます。ユーザーが他のユーザーから商品を購入できるWebサービスがあるとします。この単純なケースでは、2つのトップレベルリソースがあります。ユーザーそして製品URI階層の構造化を始めたきっかけは、
ユーザー向け:
/users
/{id}
/location
/about
/name
/seller_rating
/bought
/sold
製品の場合:
/products
/{id}
/name
/category
/description
/keywords
/buyer
/seller
どちらの場合も、各階層のオブジェクトは、他の階層のオブジェクトのサブセットを参照します。たとえば、 は、/users/{id}/boughtあるユーザーが購入した製品のリストであり、これは のサブセットです/products。また、は、/products/{id}/seller特定の製品を販売したユーザーを参照します。
これらの URI は他のオブジェクト、または他のオブジェクトのサブセットを参照するため、API は次のようなものをサポートする必要があります。/users/{id}/bought/id/descriptionおよび/products/{id}/buyer/location? これらのタイプの URI がサポートされている場合、次のようなもの/users/{id}/bought/{id}/buyer/bought/{id}/seller/name、または同様に複雑なものを止めるものは何もありません。 また、この場合、サーバー内のルーターが任意の長さの URI を解釈する必要があるため、ルーティングをどのように処理しますか?
ベストアンサー1
目標は便利なリソース識別子を構築することであり、すべてを相互参照しようとしないでください。URL 表現でデータベース関係を繰り返す必要はありません :)
次のようなリンクは/product/{id}/buyer存在してはいけません。そのリソースの識別子がすでに存在しているためです。/user/{id}
/product/{id}/buyers-listただし、購入者リストは他のコンテキストには存在しない製品のプロパティであるため、リストがあっても問題ありません。