13

HATEOAS (アプリ状態のエンジンとしてのハイパーメディア) の推奨事項は、クエリ文字列が RESTful ではないことを意味していますか?

編集：クエリ文字列は状態とあまり関係がない可能性があり、したがって質問は不可解であることが以下に示唆されました。クライアントが引数を入力しない限り、URI にクエリ文字列が含まれていても意味がないことをお勧めします。クライアントが引数を入力している場合、それはサーバー提供の URI を改ざんしていることになり、これが RESTful の原則に違反しているのではないかと思います。

編集 2: クライアントがそれを不透明なものとして扱う場合、クエリ文字列は無害に見えることに気付きました (クエリ文字列はレガシーであり、したがって便利である可能性があります)。ただし、以下の回答の 1 つで、Roy Fielding は、URI を透明にする必要があると述べていると引用されています。透明性があれば、粗悪品の使用が奨励され、HATEOAS の原則が希薄になると思います。そのような希釈は依然として HATEOAS と一致していますか? これは、REST が URI 構築のように見える密結合を必要としているかどうかという疑問を提起します。

更新この REST チュートリアルhttp://rest.elkstein.org/では、URI の構築は不適切な設計であり、RESTful ではないことが示唆されています。また、受け入れられた回答で @zoul が言ったことを繰り返します。

たとえば、「製品リスト」リクエストは製品ごとに ID を返す可能性があり、仕様ではhttp://www.acme.com/product/PRODUCT_IDを使用して追加の詳細を取得する必要があると規定されています。それは悪い設計です。むしろ、応答には各項目に実際の URL を含める必要があります: http://www.acme.com/product/001263など。はい、これは出力が大きいことを意味します。ただし、必要に応じてクライアントを新しい URL に簡単に誘導できることも意味します。

人間がこのリストを見ていて、彼/彼女が見ることができるものを望んでいない場合、「前の 10 項目」と「次の 10 項目」ボタンがあるかもしれませんが、人間がいない場合はクライアント プログラムです。 、REST のこの側面は、クライアント プログラムが使用しない可能性のあるすべての「 http://www 」のために、少し奇妙に思えます。

4

6 に答える 6

5

私の見解では、REST 自体は URI が不透明であるか透過的であるかについて何も述べていませんが、REST アプリは、サーバーがまだ通知していない URI を構築するためにクライアントに依存するべきではありません。サーバーがこれを行うにはさまざまな方法があります。たとえば、メンバーへのリンクを含む可能性のあるコレクション、または GET メソッドを使用した HTML フォームでは、params を含む URI がクライアント側で作成され、取得されます。または、URI テンプレートの標準が少なくとも 2 つ提案されています。REST にとって重要なことは、有効な URI の説明は、帯域外の API ドキュメントではなく、サーバーがクライアントに提供する応答で何らかの方法で定義する必要があるということです。

URI 透過性は、どこでも透過性が良いことと同じように良いことです。それは、設計者が当初想像していたものを超えて、リソースの斬新で計画外の使用を促進および許可しますが、(少なくとも私の理解では) ナイス URI は、インターフェイスを RESTful として記述する

于 2011-01-05T15:31:57.567 に答える
4

クライアントが引数を入力していない限り、URI にクエリ文字列が含まれていても意味がないことをお勧めします。

それは私には真実ではないようです。サーバーに一握りの写真を要求した場合、サーバーが次のようなものを返すことは完全に有効です。

<photos>
    <photo url="http://somewhere/photo?id=1"/>
    <photo url="http://somewhere/photo?id=2"/>
</photos>

/photo/id/xx代わりにパスを使用できますが、それは重要ではありません。これらの URL は、クライアントが変更しなくても使用できます。あなたの2番目のポイントについて：

クライアントが引数を入力している場合、それはサーバー提供の URI を改ざんしていることになり、これが RESTful の原則に違反しているのではないかと思います。

これがあなたの質問の核心だと思います。また、 URL を不透明な識別子として扱う必要はないと思います。Roy Fielding 自身による次の引用を参照してください。

REST では、URI が不透明である必要はありません。私の論文で不透明という言葉が出てくる唯一の場所は、私がクッキーの不透明性について不満を述べているところです. 実際、RESTful アプリケーションでは常に、元のアプリケーションで予想される以上に情報の偶発的な使用を最大化するために、人間にとって意味のある階層的な識別子を使用することが推奨されます。

于 2011-01-05T14:12:53.183 に答える
2

HATEOAS がないからといって、クエリ文字列が RESTful ではないというわけではありません。実際には、正反対の場合もあります。

ユーザーが保護されたリソースにアクセスしようとすると、ログイン画面が表示される一般的なログイン シナリオを考えてみましょう。ログイン画面への URL には多くの場合、redirectUrl という名前のクエリ文字列パラメーターが含まれています。これは、ログインが成功した後に戻る場所をログイン画面に指示します。これは、URI を使用してクライアントの状態を維持する例です。

クライアントの状態を URL に格納する別の例を次に示します: http://yuml.me/diagram/scruffy/class/[Company]<>-1>[Location], [Location]+->[Point]

于 2011-01-05T13:05:32.627 に答える
2

クエリ文字列が状態追跡とどのような関係があるのか​​わかりません。HATEOAS 原則の要点は、クライアントの状態を追跡したり、「不正行為」をしたり、データの「既知の」URL にアクセスしたりすることを控えることです。これらの URL にクエリ文字列が含まれているかどうかは、私には無関係に思えます。

おー。検索基準に従って URL の特定の部分を変更する必要がある検索 URL のようなものに興味があるかもしれません。そのような URL は事前に知っておく必要があるように見えるため、REST で排除しようとしている帯域外の情報を表しているのでしょうか? これはURLテンプレートを使えば解決できると思います。例：

client -> server
    GET /items
server -> client
    /* …whatever, an item index… */
    <search by="color">http://somewhere/items/colored/{#color_id}</search>

この方法では、検索するために先験的な URL の知識は必要なく、ハイパーメディアの状態追跡の原則に忠実でなければなりません。しかし、REST についての私の理解は非常に弱く、主に頭の中で物事を整理し、フィードバックを得るために答えています。きっともっと良い答えがあります。

于 2011-01-05T08:24:38.137 に答える
0

Darrel が言ったことの続きとして、URL を変更して 2 つ目の URL を含める必要はありません。

Cookie ベースの認証の場合、401 応答の本文内で空のフォーム アクションを使用してログイン フォームを返し、すべてのリソースに POST して処理できる一意のフィールド名を使用できます。そうすれば、リダイレクトの必要性を完全に回避できます。すべてのリソースにログイン リクエストを処理させることができない場合は、401 フォーム アクションがログイン アクション リソースを指すようにし、リダイレクト URL を隠しフィールドに入れることができます。どちらの方法でも、醜い URL-in-a-URL を回避できます。最初の方法では、RPC ログイン アクションとリダイレクトの両方が不要になり、すべての対話がリソースに集中したままになります。

于 2016-12-26T11:21:12.283 に答える