通常、REST URLはどのように定義されていますか？

Question

RESTの主な原則の1つは、すべてのリソースに対して一意のURLを作成することです。

私の質問は、これらのURLはどのように定義されていますか？

Answer 1

これはあなたの責任です。あなたはそれを理にかなって、可能な限り永続させるべきです。

例：usernameの

/users/john.doe 

とユーザーの収集のため

/users 

。

次のようなものを行うためにURLの階層的な性質を活用する必要があります。ユーザーのドキュメントのリストを参照するには

/users/john.doe/documents 

。あなたはこれをどのように構造化するかに非常に注意する必要があります。リソースURLは、サービスの最も重要な設計上の決定事項の1つであるため、設計の潜在的な影響について慎重に検討してください。

Answer 2

RESTのURLは、子供が名前を付けられたのと同じ方法で定義されています：家族名（既存の企業またはプロジェクトの標準）を使用する人もいれば、赤ちゃんの名前の本を参照する人もいます（赤ちゃんのスミス）のような既定の名前を使用し、退屈な名前を変更するプロセス（後で301のリダイレクトなど）を経なければならない人もいます。彼らが納品日までに選んだ名前。

要するに、実際に典型的なものはありません。標準フォーム生成URL（？name = value &のname = valueパラメータ）は完全に有効なREST URLです。多くの人は、http://example.com/restapi/name/value/name/valueのようなスラッシュのパスに、または暗黙の位置名http://example.com/restapi/value1/value2のように、これらのパラメータをエンコードすることを好みます。しかし、あなたは決してそれらの形式に制限されません。

Answer 3

しかし、あなたが好きです。 URLが完全に不透明であったり、URLのパスがどのような種類のリソースを必要とするかを伝えることができます。

HATEOASの原則に従い、配信しているハイパーテキストのURLにアクセスして、特定のURLを構築する方法ではなく、ナビゲートする方法のみをクライアントが知りたい場合があります。

I.e.ルートURLを開始し、他のすべてのリソースをそこからのナビゲーションで到達可能にすることができます。 自分自身を特定のURLテンプレートに縛らないでください。これは、REST APIを拡張して改善する能力にのみ影響します。

Answer 4

RESTは、分散システムを構築するためのアーキテクチャスタイルです。一般的には、クライアントアプリケーションとサーバーアプリケーションがあることを意味します。クライアントアプリケーションがサーバー上の情報にアクセスする必要がある場合は、その情報を識別するために使用できるURLを作成します。

URLの構造はクライアントアプリケーションにとって本当に重要ではないため、使用しているサーバーフレームワークで最も簡単な構造を使用してください。