あなたの謙虚な意見では:REST URLを自分のアーキテクチャ内のサービス/ファイルにマップするためのベストプラクティスのアプローチは何でしょうか(ここではMVCパターンを想定しましょう)?
2 に答える
ダレルの答えに加えて:
HTTP URI の階層的な性質を利用します。すべてのパス セグメントは、管理対象アイテム (注文、顧客など) の全体的な空間にドリルダウンするものと考えてください。ある時点で、複数のディメンション (クエリなど) に沿ってコレクションに「インデックスを付ける」必要がある場合は、クエリ文字列パラメーターを使用します。
/service/products/cars/japanese-cars/toyota/corola/&priceMin=2000&priceMax=5000
(darrelが言ったように)構造はクライアントに対して不透明でなければならないことに注意してください。つまり、クライアントは実行時にパラメーターを検出する必要があります (フォームまたは URI テンプレートはそのためのものです)。もちろん、クライアントとサーバーは、たとえば priceMin の意味について共有された知識が必要です。その知識は、リンク関係の仕様など、設計時の仕様に含まれている必要があります。詳細な使用例については、 http: //www.opensearch.org を参照してください。
また興味深いのは、URI のホスト部分です。ある段階でサービスの一部を別のマシンに移動する必要がある場合は、関連情報がドメイン部分に含まれるように URI を設計してください。次に、単純な DNS を使用して、要求を別のマシンにルーティングできます。
HTH、1月
URL をリソースにマップする最適な方法は、REST サービスを提供するために使用する Web フレームワークによって異なります。お手持ちのツールで管理しやすい URL 構造を選択してください。
URL 構造は、サービスのクライアントに対して完全に不透明であるべきです。
私の意見では、最も重要なことは、URL を見ているときに、サーバー上のどのコントローラーがその URL に応答するかを比較的簡単に推測できるはずだということです。これにより、開発とデバッグがはるかに簡単になります。