残りのAPIリソース内の個々のユーザーデータを返すのは問題ありませんか？

Question

たとえば、書籍の詳細をモバイルアプリケーションに渡すAPIを持っているとします。ユーザーは書籍のリストをブラウズし、希望リストに書籍を追加することができます。

私の質問は、1つの本または書籍のコレクションを返すとき、各書籍リソースにユーザー固有の情報を含めることをお勧めしますか？これはつまり、各本には、その本がユーザーの希望リストにあるかどうかを示すフィールドを含めることができますか、このリストは別に返され、このチェックを実行するモバイルアプリケーションまでです。

モバイルアプリの開発者は/ booksに電話をかけて、このようなレスポンスを受け取ることをお勧めします。

{ 
    "books": [ 
    { 
     "id":1, 
     "name": "How to be good at everything", 
     "price": 3.99, 
     "in_wish_list": true 
    }, 
    { 
     "id":2, 
     "name": "How to be good at nothing", 
     "price": 6.50, 
     "in_wish_list": false 
    } 
    ] 
} 

私はこのデータを複数のエンドポイントに分割したいと考えています。

/ユーザー/ 29 /ウィッシュリスト

{ 
    "wishlist": [1,7,9,34,28] 
} 

/ブック

{ 
    "books": [ 
    { 
     "id":1, 
     "name": "How to be good at everything", 
     "price": 3.99 
    }, 
    { 
     "id":2, 
     "name": "How to be good at nothing", 
     "price": 6.50 
    } 
    ] 
} 

モバイルアプリケーションは本がウィッシュリストのユーザーであるかどうかを決定する責任があるこの方法です。

ユーザーのデータをブックリソースに埋め込むメリットがありますが、それは正しいとは感じません。

このような状況を他のどのように管理するのだろうか？

Answer 1

今、あなたのAPIを誰が消費するのか、どのように使用するのかによって異なります。ユーザーの欲しい書籍を表示する必要がある場合は、別のエンドポイントが必要です。もちろん、モバイルクライアントの開発者は、いくつかの小さなクライアントへの多額の呼び出しを好むでしょうが、別のユーザーウィッシュリストエンドポイント（それについてのユースケースシナリオがあれば）を妥協して両方持っていて、 APIへの呼び出し回数が減少することさえあります。