11

REST URI の設計については多くの議論がありますが、私の質問に正確に答えたものはありません。

タスクやその他のリスト (リスト = ノードおよびタスク = リーフ) を含むいくつかのリストがあるとします。

私たちは次のようなものを持つことができます 

/lists/{id_list1}/lists/{id_list2}/lists/{id_list3}/tasks/{id_task1}

または多分短いバージョン:

/lists/{id_list1}/{id_list2}/{id_list3}/{id_task1}

しかし、本当に深い木はどうですか？

私はまた、次のように翻訳できる親子関係についても考えていました

/lists/{id_list_parent}/{id_list_or_task_child}

でもなんか物足りない気がする…

REST URI ツリーのスマートな設計とは?

編集

返事が遅くなってすみません！

したがって、API URI とブラウザー URI という 2 つのニーズを混ぜ合わせていたと思います。

これが私が物事を見る方法です：

API 側では、書き込みメソッドと読み取りメソッドの両方にこれらの URI のみを使用します (たとえば、create の場合、末尾の「/id」は必要ありません)。

/lists/id
/tasks/id

ただし、私のブラウザでは、次のようなものがあります。

/lists/id/lists/id/tasks/

最初の部分 (/lists/id) のみがサーバーによって解釈され、2 番目の部分 (lists/id/tasks/) はクライアント側の JavaScript によって使用され、サーバーから受信したリストのサブリストのタスクを検索します。 .

このアプローチについてどう思いますか？

4

2 に答える 2

12

URI を介してツリーを表す必要はありますか? それらが単にノード自体への参照であり、関係がハイパーメディア タイプのリンクを介してモデル化されている場合。

それ以外では、次のように考えています。

/lists/{nodeId}/children

また、直接の子のリストを親に返すことができます。

次のようなこともできます。

/lists/{nodeId}/children?depth=3

ツリーの次の 3 つのレベルを結果に返します。

/lists/{nodeId}/children?depth=infinite

そのノードからブランチ全体を返すことができます。

于 2012-05-29T22:04:20.320 に答える
0

URI を使用してこの制約を強制することは正しくないようです。ある種のペイロード (JSON、XML など) を持つ PUT リクエストを受け入れます。

PUT /tasklist

lists: [{
   id: 1234,
   id: 12345,
   tasks: [{
      id: foo,
      id: bar,
      id: baz
   }]
}]

URL は、ここでやりすぎていることを示しているようです (IMHO)。通常、単一のリソースと対話しますが、ユース ケースでは、コンテキストに応じて階層化された複数のリソースを同時に操作していることを意味します。

于 2012-05-29T22:04:17.933 に答える