すべてのリソースに対して一般的なエンドポイントを作成しない、またはすべてのリソースを1つに汎用化する理由はありますか？一般的なエンドポイントと特定のエンドポイント - 安らかなAPIデザイン
Facebook Graph APIのように構築されているようです。 /api/users、/api/companiesなどはありません。あるいは、サーバー上のさまざまなリソースと話すための単なる一般的なインターフェースですか？
明らかに、このアプローチは、異なるリソースが同様の機能を持つ場合、バックエンド上のコード複製の数を減らすことができます。
一般的なエンドポイントをすべてのリソースに作成したり、すべてのリソースを1つに一般化したりする理由はありますか。
はい - ただし、これらの理由は、すべての状況で等しく適用されません。
疑問がある場合は、Chapter 5 of Fielding's dissertationを確認してください。
RESTインターフェイスは、大規模なハイパーメディアデータ転送に効率的に設計され、Webの一般的なケースを最適化するように設計されていますが、他の形式のアーキテクチャとのやりとりには最適ではありません。特に資源に関しては
- イアン・ロビンソンは、彼の話では、このの一部をカバー：The Counterintuitive Web
を専門と革新がオープンセットに依存します。
RPCでは、エンドポイントのセットが閉じられ、RPCに送信できる一連のメッセージが開いています。新しいメッセージを作成することで革新します。 RESTでは、一連のメッセージは閉じられ、一連のエンドポイントは開いています。新しいエンドポイントを作成することで革新します。
後者のアプローチの利点は、限られた数のメッセージの制限された理解しか必要としないため、汎用コンポーネントを使用して作業を配布できることです。例えば、キャッシュは何をすべきかを理解するために、ペイロードの詳細と意図を理解する必要はありません。彼らは識別子といくつかの標準化されたメタデータだけを必要とし、彼らは良いです。
今、GraphQLを使用すると、a caching storyがあります。しかし、見過ごさないでください：その戦略は "ああ、ただの商品ウェブキャッシュを差し込む"ではありません。
コースの馬;これはトレードオフであり、正しい/間違った二分法ではありません。あなたのプロジェクトが非常に壊滅的に成功してRESTアーキテクチャ上の制約だけであなたを救うことができるなら、あなたは既に問題を他の人に引き渡し、あなたの好きな熱帯島に引退しました。