10

私は、相互依存関係を持つリソース コレクションを定義する正しい方法について熟考してきました。

たとえば、URI を介して独立してアクセスできる「ドキュメント」と「コメント」を考えてみましょう。

/documents/{doc-uri}
/comments/{comment-id}

ただし、通常は、特定のドキュメントに関連するコメントのコレクションが必要です。これにより、これをどのように設計する必要があるかについて設計上の問題が生じます。

いくつかの主なオプションが表示されます。

1.) コメントのドキュメント uri の後にコレクション uri を指定します。

GET /documents/{doc-uri}/comments/

2.) コメント コレクションにパラメーターを指定して、ドキュメントごとに選択する

GET /comments/{comment-id}?related-doc={doc-uri}

3.) コンテンツ ネゴシエーションを使用して、関連するコメントが Accept ヘッダー経由で返されるように要求します。

// Get all the comments for a document
GET /documents/{doc-uri} Accept: application/vnd.comments+xml
// Create a new comment
POST /documents/{doc-uri} Content-Type: application/vnd.comment+xml <comment>...</comment>

方法 1 には、ドキュメントのコンテキストにコメントを自動的に配置できるという利点があります。これは、POST/PUT を使用してコメントを作成、更新、および削除するときにも便利です。ただし、ドキュメントのコンテキスト外のコメントへのグローバル アクセスは提供しません。したがって、システム内のすべてのコメントを検索したい場合は、方法 2 が必要になります。

方法 2 は #1 と同じ利点の多くを提供しますが、ドキュメントのコンテキストなしでコメントを作成しても意味がありません。コメントはドキュメントに明示的に関連付ける必要があるためです。

方法 3 は、GET および POST/create の観点からは興味深いものですが、更新と削除ではやや面倒です。

これらすべての方法の長所と短所を見ることができるので、以前にこの問題にアプローチして解決した可能性のある人からのガイダンスを探しています.

方法 1 と 2 の両方を実行することを検討しているため、必要なすべての機能を提供できますが、機能を過度に複雑化/複製しているのではないかと懸念しています。

4

2 に答える 2

9

REST APIはハイパーメディア ドリブンである必要があります。Hypermedia as the Engine of Application State (HATEOAS)制約を参照してください。URLPatterns は RESTful ではないため、時間を無駄にしないでください。URLPattern は、クライアントとサーバー間の密結合を意味します。簡単に言うと、クライアントは URL がどのように見えるかを認識し、それらを構築する能力を持っている必要があります。

ユースケースについて、次の REST 設計を検討してください。

ドキュメントの表現には、クライアントがコメントを投稿したり、GET を使用してドキュメントのすべてのコメントを取得したりできるリンクが含まれています。例えば

{
  ...
  "comments" : {
      "href": ".. url ..",
      "rel": ["create-new-comment", "list-comments"]
  }
}

クライアントはこの URL を受け取り、その URL に対して GET メソッドまたは POST メソッドを実行するだけです。URL がどのようなものかを知らなくても、次のようになります。

この投稿も参照してください。

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

于 2013-03-08T14:18:21.950 に答える
0

方法 1 と 2 の組み合わせは良さそうです。方法 2 で言うように、文書コンテキストなしでコメントを作成する意味はあまりありません。両方の間に親子関係が存在するためです。また、/comments/ドキュメントなしでの作成を避けるために、URI を読み取り専用リソースにすることもできます。

filip26 が言うように、残りの API はハイパーメディア駆動型である必要がありますが、それは URL パターンが重要ではないという意味ではありません。リソースに複数の URI がある場合、クライアントがそれらを見つけやすい場合、1 つまたは複数の URI を持つリソースを持つことができます。欠点は一部のクライアントは別の URI ではなく 1 つの URI を使用するため、混乱を招く可能性があります。そのため、リソースに正規の URI を使用できます。クライアントがこの正規の URI を介してリソースにアクセスする200 OKと、クライアントが他の URI のいずれかを要求したときに、を送り返すことができます。正規の uri と一緒に 303 "See also" を返すことができます。

于 2013-05-26T08:55:22.230 に答える