私はサーバー側の Web 開発は初めてで、最近、RESTful API の実装について多くのことを読んでいます。私がまだ立ち往生している REST API の側面の 1 つは、クライアントが対話できるリソースを識別する URI 階層を構築する方法です。具体的には、階層をどのように詳細に作成するか、およびリソースが他のリソース タイプで構成されている場合に何をすべきかを決定することに固執しています。
これは、うまくいけば私の言いたいことを示す例です。ユーザーが他のユーザーから商品を購入できる Web サービスがあるとします。したがって、この単純なケースでは、2 つの最上位リソースusersとproductsがあります。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 を解釈する必要があるため、ルーティングをどのように処理しますか?