基本的に、私のアプリの1つの機能は、ログに記録されたユーザーの友達を取得することです。
実際、私は両方の種類のエンドポイントの間で迷っています：
1を使用userIdすると、認証トークンを通じて到達可能になります。
2を使用すると、サーバーは、渡さuserIdれたと、認証トークンで指定されたログに記録されたユーザーIDとの対応をさらにチェックして、友達などの他のユーザーデータへの悪意のあるアクセスを回避する必要があります。
したがって、1で十分ですが、標準のレストURLのようには聞こえません。
良い習慣とは何ですか？
回答:
最初のソリューションには、データの重複を回避できるという利点があります。要求は明らかに意味します：
こんにちは、ジョンです。私のリスト与える私の友人。
できれば、に短縮しGET /api/friendsます。
一方、他のユーザーの友達にアクセスできることを期待している場合は、2番目のソリューションが適切です。リクエストとは：
こんにちは、ジョンです。ジョンの友達のリストをください。
しかし、以下の場合もあります。
こんにちは、ジョンです。メアリーの友達のリストをください。
たとえば、そのような変更が可能な状況の1つは、自分の友達だけでなく、友達の友達も見つけることができる場合です。
GET /api/friends私は名前を変更しますGET /api/myFriends。発見可能性の観点から、より自己文書化します。さらに、RESTを使用すると、ブラウザー/プロキシキャッシュがそれをどのように処理するかを考えるのに役立ちます。ではGET /api/myFriends、それあなたが原因キャッシュに間違った友人を表示するバグを持つことが完全に可能です。
Rest Apiはハイパーテキスト駆動である必要があります！標準のHTMLページで1つのリンクから別のリンクをクリックするように。
URLは、リソースに対する一意の識別子です。複数のリソースを表すURLを持つことは、ReSTと完全に一致しません。
あなたの例では、次のURL：
/api/users/:userId
：userIdフレンズURLへの応答にリンクが必要です
Roy Fieldingの論文には、ReSTに準拠するために必要な一連の制約が含まれています。
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://fr.slideshare.net/rnewton/2013-06q-connycrestfulwebapis http：//www.ics。 uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm