11

バージョン管理されたリソースの URL に関する適切な概念を理解するのに非常に苦労しています。

RCS などの古い学校のような、バージョン管理システムと非常によく似た方法でレシピを追跡するアプリケーションがあるとします。各バージョンは、しばらくの間作業コピーとして使用でき、その後、そこから新しいバージョンが作成されます。各バージョンにはコメントが関連付けられており、コメントは共有されません。いつでも履歴をさかのぼって、進化したレシピを見ることができますが、各インスタンスは常に同じレシピのバージョンと見なされます。これらを参照する URL を作成する最も適切な方法を見つけようとしていますが、サブリソースと一時リソースなどの違いのいくつかを理解するのに苦労しています。

これが行われるのを私が見た2つの主な方法は次のとおりです。

> 1) query parameters
> -- /recipes/ultimate-thing                -> List of available versions of Ultimate Thing
> -- /recipes/ultimate-thing?version=2      -> Version 2 of Ultimate Thing
> -- /recipes/ultimate-thing?version=latest -> Current working version of Ultimate Thing

2a) Nested resources with versions considered subresources
-- /recipes/ultimate-thing/versions/      -> List of available versions of Ultimate Thing
-- /recipes/ultimate-thing/versions/2     -> Version 2 of Ultimate Thing
-- /recipes/ultimate-thing                -> Current working version of Ultimate Thing

2b) Nested resources with the list at the resource
-- /recipes/ultimate-thing                 -> List of available versions of Ultimate Thing
-- /recipes/ultimate-thing/versions/2      -> Version 2 of Ultimate Thing
-- /recipes/ultimate-thing/versions/latest -> Current working version of Ultimate Thing

ある方法を自分に納得させようとするたびに、その方法の適切な正当化を構築するための理解が不足しているように感じます.

1 は多くの Rails 関係者に好まれているようですが、特定のリソース ( /recipes/ultimate-thing )に POST して以来、新しいバージョンのレシピをいつ作成したいかを明確にする方法がわかりません。通常、リソースが存在しない場合はその名前でリソースを作成する必要があります。作成する代わりに 404 のようなものを返し、/recipes に投稿して新しいレシピを作成し、POST を/recipes/ultimateに許可するのが適切でしょうか? -新しいバージョンを作成すること? また、コメントはどのように表されますか? バージョンがなければ/recipes/ultimate-thing/comments のようなことができますが、/recipes/ultimate-thing/comments?version=latest醜いように見えますが、2b はより明確な「究極のレシピの最新バージョンのコメント」のように見えますが、2a は最もきれいに見えます。

実際、私は一般的に 2a が一番好きですが、バージョンがレシピのサブリソースであることを理解するのに苦労しています。バージョンはレシピですが、そのレシピのすべてのバージョンは論理的にグループ化する必要があるためです。

また、stackoverflow で 2b も見ましたが、 /recipes/ultimate-thing/version/latest/comments のようなものが常に必要になるため、冗長すぎるようです。バージョンを、注釈を付けることができる指示を含む材料のコレクションと考えると、これは最も理にかなっていますが、レシピは同様の意図を共有するバージョンのコレクションです。

私は2aが本当に好きですが、私が見逃しているアプローチでそれを悪い考えにするものはありますか? 1 がどのように機能するかについて、多くの人に好まれているように見えることをより理にかなっていますか?

それとも、 /recipes/ultimate-thing/latestや/recipes/ultimate-thing/2/comments のようなことを常に行う方が理にかなっていますか?

これがこれに非常に適したフォーラムであるかどうかはわかりませんが、あるアプローチが別のアプローチよりも優れている理由を理解するために、それについて議論したいと思います.

4

4 に答える 4

9

わお。良い質問。私も、RESTの最大の課題の1つは、厳密な仕様ではなく、スタイルであることに気づきました。スタイルはよく理解されていないようで、それを強制するものは何もありません。

簡単な答え：スタイル＃1：/レシピ/ケーキ？バージョン= 2

このスタイルは私に最も適しているようです。クエリパラメータがURIの一部と見なされることがわかったのは、Googleですばやく検索した後でした。したがって、URIに識別属性を入れることが適切であるように思われます。

スタイル2と3は、パスセグメントがIDとサブリソースを表す他のREST規則に違反しているようです。したがって、スタイル/ recipes / cake/2はID2の「cake」リソースのように見えます。/recipes/cake/ version / 2は、実際には親の属性であるにもかかわらず、「version」をサブリソースのように見せます。資源。

于 2013-02-27T22:28:36.720 に答える
4

昨年末にこのパターンを実装したばかりで、2a と 2b の組み合わせに従いました。

2c) Nested resources with versions considered subsets
-- /recipes/ultimate-thing/versions/      -> List of available versions of Ultimate Thing
-- /recipes/ultimate-thing/versions/2     -> Version 2 of Ultimate Thing
-- /recipes/ultimate-thing/versions/latest-> Redirect to current working version of Ultimate Thing

URI が何かを識別するかのように、長い URI を「サブリソース」または「属性」と考えないでください。URI を識別データとして扱う方がはるかに自然であり、HTTP URI は階層的であるため、より長い URIはデータのサブセットを参照します。コレクション内のアイテムはデータです。つまり、コレクション内のすべてのデータのサブセットです。「もの」の「属性」はデータです: そのものに関するすべてのデータのサブセットです。「サブリソース」は、親から独立して存在しない「もの」に関するデータであり、したがって、親に関するすべてのデータのサブセットです。

あなたの場合、recipes/cherry-pie/特定のバージョンの指示ではなく、チェリーパイとは何か、どのように作るかについてのすべてのデータと考えるために、あまりにも多くの精神的な柔道を実行する必要はありません. これには、身元情報やその他のバージョン固有ではないデータだけでなく、 へのリンクversions/、および誰かが直面した歴史や面白いビデオへのリンクも含まれます。URIrecipes/cherry-pie/versions/は、バージョン管理されたすべてのチェリー パイ データのサブセットです。一般に、フォームの各 URI へのリンクの集まりにすぎませんrecipes/cherry-pie/versions/{version}/。また、一時的なリダイレクトを行う、または最新バージョンが何であれ、versions/への文書化されたリンクに含めます。recipes/cherry-pie/versions/latest/recipes/cherry-pie/versions/182/

これはクライアントにとって非常に自然に機能します。多くの人が、リソースの爆発的な増加につまずき、貧弱なクライアントは追いつけないだろうと考えています。しかし、自然なユーザー ワークフローの境界に沿ってリソースを分割すれば、問題は発生しません。一部のクライアントは、一連のレシピを参照する必要があります。(バージョンに関係なく) 単一のレシピにドリルダウンするものもあります。バージョンがいくつあるか、どれが最新かを知りたくてドリルダウンして、その中から選択する人もいます。ドリルダウンして単一のバージョンを取得するものもあります。単一のレシピまたはすべてのレシピのすべてのバージョンを表示したい場合は、おそらく何か間違ったことをしている可能性があります (そうでない場合はまれですが、recipes/byname/pie/quickviewすべてのデータを収集して大量にキャッシュするなどの別のリソースを設計してください)。 ）。

于 2013-02-28T16:30:08.677 に答える
1

それはすべて、リソースのバージョンをどのように見ているかによって異なります。これらは wiki のような履歴追跡に使用されるだけでしょうか、それともバージョンは別のリソースです。最初のケースでは、EJK の回答が適切な解決策のように思えます。2 番目のケースでは、リソースのバージョン/バリエーションの新しい一意の識別子を作成することが別の解決策になる可能性があります。例えば：

3) Resources with versions
-- /recipes/                          -> List of available recipes versions
-- /recipes/ultimate-thing-version-2  -> Version 2 of Ultimate Thing
-- /recipes/ultimate-thing            -> The "offical" version of Ultimate Thing

リソースが相互に異なる場合、これはさらに好ましい解決策です。

3) List of recipes
-- /recipes/                           -> List of available recipes and variations
-- /recipes/ultimate-thing-with-sugar  -> The Ultimate Thing recipe with sugar
-- /recipes/ultimate-thing-with-honey  -> The Ultimate Thing recipe with honey
于 2015-10-17T17:47:39.163 に答える