RESTful API：ネストされたリソースを整理する方法

Question

APIルート構造を整理する方法について質問があります。 RESTfulなAPIを構築することに関する多くの書籍を読んできましたが、その答えが見つかりませんでした。 すべての書籍は、単純なCRUDアクションとネストされたリソースについて、1つのレベルで説明しています。 のように/usersおよび/users/1/posts。それに問題はない。

例：

しかし、のがより困難実際の生活の例を見てみましょう：carsのデータベーステーブルの

GET /cars // List of cars 
GET /cars/{car_id} // Get single car 
POST /cars // Add new car 
PUT /cars/{car_id} // Update existing car 
DELETE /cars/{car_id} // Delete car by specified ID 

構造は、これまで

Table "cars" 
    - id 
    - uuid 
    - make 
    - model 
    - year 
    - created_at 
    - updated_at 
    - deleted_at 

んの問題もないだろうが、ネストされたリソースを追加する必要があります。 指定された車で行われたすべての修理。データベーステーブルの

GET /cars/{car_id}/repairs // List of repairs that were done with car 
GET /cars/{car_id}/repairs/{repair_id} // Get single repair 
POST /cars/{car_id}/repairs // Add new repair for specified car 
PUT /cars/{car_id}/repairs/{repair_id} // Update existing repair for specified car 
DELETE /cars/{car_id}/repairs/{repair_id} // Delete repair by specified ID 

構造

Table "car_repairs" 
    - id 
    - uuid 
    - car_id (foreign key to cars) 
    - title 
    - description 
    - repair_started_at 
    - repair_ended_at 
    - created_at 
    - updated_at 
    - deleted_at 

今のところ問題はないでしょう。すべての本のように。 /usersルートおよびネストされたルート/users/1/posts。しかし、ここでは、別のレベルの入れ子を追加する必要があるときに問題が始まります。

私は

GET /cars/{car_id}/repairs/{repair_id}/defects // List of all defects that were found for specified repair for speicified car 
GET /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Get single defect 
POST /cars/{car_id}/repairs/{repair_id}/defects // Add new defect 
PUT /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Update existing defect 
DELETE /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Delete existing defect 

テーブルの構造は次のようになり、車が修理にあった際に発見されたすべての欠陥のためのCRUDルートが必要になります。

Table "car_repair_defects" 
    - id 
    - uud 
    - car_id 
    - repair_id 
    - name 
    - description 
    - created_at 
    - updated_at 
    - deleted_at 

QUESTSIONS：

ここでの対処方法、通常の練習のレベルは.../defectsですか？私は一例で、ネストの他、4レベルを追加する必要がある場合

は、状況を考えてみましょう、のために使用されたすべての部品は、ベストプラクティスは、RESTfulなAPIの中にネスト資源が

一つは、と言うことができたときにどのような欠陥

ましたこれは入れ子にすることなく行うことができます。例/cars/repairs/defects/partsしかし、ネストされたリソースを持つRESTfulサンプルはどうでしょうか。次に、ネストリソース0、1、2、3の最大レベルは何ですか？

また、ネストすることなく実行される場合は、たとえば、可能性のあるすべての車の欠陥をリストする辞書ルート/defectsを作成する必要があります。だから名前の衝突があります。

また、ネスティングがない場合、ネスティングでフィルタリングするアイテムをどのようにフィルタリングしますか？このよう

defects?car_id=1&repair_id=2&defect_id=3

？これは醜いように見えます。

誰かが本や記事を指し示すことができますか、または以前にリストされた最大のネスティングと質問について答えてください。 ありがとうございます。

Answer 1

ここに重要な点があります。ケアあなたの識別子に使用するスペルはありません。

つまり、RESTはこれらのURIのそれぞれが同等に良いとみなします。

/cars/{car_id}/repairs/{repair_id}/defects 
/08617423-cc74-4967-9a67-49e4171f01b7 

限りクライアントに関しては、識別子は不透明です。 URIへの情報のエンコードは、独自の目的でサーバーの裁量で行われます。

それより、識別子スペルの規則は効果的なコードスタイルの規則です。地元のスタイルと一致するスペルを使用する。

クライアントの観点からは、識別子はではなく、はリソースのセマンティクスを記述します。それがハイパーメディア表現の仕事です。