18

既存のRestfulWebサービスを可能な限りHATEOSに変換した場合の潜在的なメリットについて多くのことを読んでいます。次の有効な利用可能なアクションを記憶する際の消費者の負担を軽減するために、ペイロードにリンクを提供することの重要性を理解しています。ただし、実際にRestfulWebサービスの利用者にどのように役立つかについて頭を悩ませているようには思えません。

説明のために、コーヒーの注文についてのRestInPracticeの本からこの例を取り上げます。-

<order xmlns="http://schemas.restbucks.com">
  <location>takeAway</location>
  <item>
    <name>latte</name>
    <quantity>1</quantity>
    <milk>whole</milk>
    <size>small</size>
  </item>
  <cost>2.0</cost>
  <status>payment-expected</status>
  <link rel="payment" href="https://restbucks.com/payment/1234" />
</order>

基本的に、これにより、消費者は<link>タグで定義された支払いを行うことができます。ただし、実際には、コンシューマーは、そのWebサービス呼び出しのすべてのセマンティクス、たとえば、使用するメソッド（POSTまたはPUT）、支払いを行うためにペイロードで使用する要求パラメーターなどを知る必要があります。 ..言い換えると、コンシューマーは、このWebサービスを正常に呼び出す方法を知るためにWADLドキュメントに依存する必要があります。これらのタグは、すべてが1つの特定のアイテムに対してGETを使用している場合、おそらくより意味があります。そうでなければ、ここでリンクを定義することにあまりメリットはありません...消費者が次に呼び出すことができるアクションを知っているという事実を除けば、WADLを参照して正しく呼び出す方法を決定します。

<link>私の次の懸念は、すべてのタグで非常に重いペイロードになってしまう可能性です。たとえば、/ projects / 1 / usersのGETが、プロジェクト1に属するすべてのユーザー情報を返す場合、次のタグが付けられると思います。-

<project>
    <users>
        <user id="12" name="mike" ... />
        <user id="23" name="kurt" ... />
        <user id="65" name="corey" ... />
    </user>
    <links>
        <link rel="self" href="http://server/projects/1/users"/>
        <link rel="create_user" href="http://server/projects/1/users"/>

        <link rel="get_user_mike" href="http://server/projects/1/users/12"/>
        <link rel="get_user_kurt" href="http://server/projects/1/users/23"/>
        <link rel="get_user_corey" href="http://server/projects/1/users/65"/>
        ...
    </links>
</project>

プロジェクトにたとえば500ユーザーが含まれている場合、ペイロードに500ユーザーリンクが含まれていませんか？それ以外の場合、この状況を処理するためにWebサービスを再設計するための最良のアプローチは何ですか？それとも、これは現実の世界で受け入れられますか？

どんな考えや提案もここで大歓迎です。ありがとうございました。

4

4 に答える 4

9

なぜそれが正しいのかを考えるために、HATEOASアプローチなしでAPIを想像してください。ドキュメント（または、それがあなたのものである場合はWADL）で可能なすべてのURIスキームを公開する必要があります。クライアントを壊さずにそれらを変更することはできません。

本質的に、クライアントは、選択したURIレイアウトと密接に結びついています。これは、リンクがどのように見えるかを文書化するのではなく、メディアタイプのどこにリンクがあるかを文書化するだけで簡単に回避できる結合のレベルです。

そうは言っても、アプリケーションがそのアプローチを取る必要があるのは問題ないかもしれませんが、それは問題ありません。長い間、URIレイアウトに固執することを覚えておいてください。しかし、あなたは良い仲間になるでしょう。

于 2012-07-03T03:44:39.453 に答える
5

あなたの特定の例では、HTMLに戻るのが理にかなっていると思います。500個のリソースのリストをHTMLで表示する場合、ユーザーがより多くの情報を入手できるように、各リソースへのリンクを含めますか？あなたはおそらくそうするでしょう。REST APIもそれほど違いはありません。500個のリソースのリストを返す場合は、500個のリンクを含める必要があります。これにより、ユーザーは各リソースに関する詳細情報を取得できます。

クライアントがいくつかのIDまたは名前に基づいてURLを構築することを期待することは、ユーザーにブラウザーのアドレスバーに手動でURLを入力するように求めるようなものです。

これは特にこれに関する非常に良い記事（デッドリンク）です：

HTMLファイルがタグで相互にリンクするのと同じように、またはXMLファイルがXLinkで相互にリンクするのと同じように、すべての状態転送は、表現内にあるリンクへの反応としてのみ実行する必要があります。

于 2012-07-03T08:32:27.107 に答える
0

500ユーザーのことについての単なる副次的な点：私は専門家ではありませんが、あなたが安らかにページネーションを提供できることを理解しています：

/ project / 1 / users / pages / 1

<links>
    ...
    <link rel="get_user_mike" href="http://server/projects/1/users/12"/>
    <link rel="get_user_kurt" href="http://server/projects/1/users/23"/>
    <link rel="get_user_corey" href="http://server/projects/1/users/65"/>
    <link rel="get_page_2" href="http://server/projects/1/users/pages/2"/>
</links>
于 2013-09-28T04:29:23.617 に答える
0

これは実際には答えではなく、HATEOASを採用するためのヒントです。何百ものリンクを含める必要はありません。500の完全なリストへの1つのリンク、リンクのページ化されたサブセットへの1つのリンクを含めるか、応答にページ化されたサブセットを含めて次のページのリンクを追加することができます。

WADLに対応して、コンテンツ形式が何であれ、組み込みの機能を使用する必要があります。たとえば、HTMLでは、クライアントがGET要求を行う必要があることを示す要素やLINK、POST要求の要素を使用します。明らかに、他のフォーマットとAPI XLinkとXMLHTTPRequestは、HTMLよりもHTTPをサポートしています。https://datatracker.ietf.org/doc/html/draft-nottingham-link-hintをご覧ください。AFORM

于 2013-09-28T18:59:45.983 に答える