9

ここで SO に関する多くの議論を読み、Jon Moore のプレゼンテーション(多くのことを説明していました) を見て、HATEOAS に関する Roy Fielding のブログ投稿を読みましたが、クライアントの設計に関してはまだ少し理解できていません。

API の質問

今のところ、リソースを表すフォーム/アンカーと定義リストを含む xhtml を返すだけです。次のスニペットは、フォーム/アンカー/リストのレイアウト方法を詳しく説明しています。

# anchors
<li class='docs_url/#resourcename'>
  <a rel='self' href='resource location'></a>
</li>

# forms
<form action='action_url' method='whatever_method' class='???'></form>

# lists
<dl class='docs_url/#resourcename'>
    <dt>property</dt>
    <dd>value</dd>
</dl>

私の質問は主にフォームに関するものです。Jon の講演では、(add_location_form) などのフォーム タイプと、それらに必要な入力について説明しています。私は多くのリソースを持っていませんが、抽象的なフォームタイプ (追加、削除、更新など) について考えていました。(追加、更新) の場合は、ターゲットリソースの有効な表現を送信する必要があることをドキュメントに書き留めておきます。そして、識別子を送信する必要があることを削除します。

質問 1: HATEOAS の概念では、(追加、削除、更新などを分類することによって) クライアントにフォームを「発見」させ、提供したすべてのデータを送り返すだけでよいのではないでしょうか? ここでの私の本当の質問 (議論を意図したものではありません) は、これが良い慣行に従っているかどうかです。

クライアントの質問

HATEOAS に続いて、リソースに対するアクションを検出可能にすると、クライアント コード (API のコンシューマー) とその UI にどのような影響がありますか。UI が利用可能なアクションのみを表示する必要があるというこれらの原則に従うのは素晴らしいことですが、それはどのように実装されているのでしょうか?

私の現在のアプローチは、応答を xml として解析し、xpath を使用して、クライアント開発時に既知のアクション (文書化されたフォーム クラス、つまり追加、削除、更新) を探し、利用可能な場合は UI コントロールを表示することです。

質問 2:発見の仕方が間違っていますか? それとも、クライアントに関する限り、これはあまりにも多くの魔法ですか (フォームクラスを知っています)? これは、クライアントが各リソースで利用可能なアクションを知っていることを前提としているのではないでしょうか (それはクライアントを作成する理由のようなものなので、これで問題ないかもしれません)。また、リソースへのアクション (フォーム クラス) のマッピングを文書化する必要があります。 、またはフォームクラスを文書化して、クライアント (およびクライアント開発者) がそれらを調査および発見できるようにするだけですか?

私はこれでどこにでもいることを知っていますが、どんな洞察も大歓迎です。これら 2 つの質問のいずれかによく答える回答を回答済みとしてマークします。ありがとう！

4

1 に答える 1

7

いいえ、あなたはかなり的を射ています。

ブラウザーは単純に HTML ペイロードをレンダリングし、ヒューマンに依存して実際に解釈し、意味を見つけ、フォームを適切に入力する可能性があります。

これまでのところ、マシンクライアントは「解釈」部分でかなりうまくいかない傾向があります。そのため、開発者は事前に決定を下し、非常に詳細にマシン クライアントをガイドする必要があります。

理想的には、「スマート」な HATEOS クライアントは、特定の事実を持ち、コンテキストを認識して、それらの事実をサービスの要件により適切にマッピングできるようになります。

それが私たちの仕事だからですよね？「ああ、彼らは名前、住所、クレジットカード番号が欲しい」というフォームが表示されます。「名前」、「住所」、「クレジットカード」番号が何を意味するかを知っているだけでなく、それらが私の名前、クレジットカードに記載されている人の名前、または発送される人の名前を意味することも直感的に理解できますに。

機械は「直観」の部分でも簡単に失敗します。したがって、開発者として、正しい事実とそれらがどのように配置されるかを判断するために必要であると思われるもののロジックをコード化することができます。

しかし、理想的なクライアントに戻ると、各フォームを見て、フィールドが何を求めているかを「認識」し、「ファクト」の内部リストを参照してから、リクエストのペイロードを適切に入力し、最終的にリクエストを行います。

これを行うための単純で明らかに脆弱な方法は、パラメーター名を内部データに単純にマップすることであることがわかります。パラメータ名が「name」の場合、firstName + " " + lastName のようにハード コードできます。または、実際の rel が配送について話していることを「知っている」と考えて、shipTo.firstName + " " + shipTo.lastName を使用することもできます。

時間の経過とともに、理想的にはマッピングなどのコレクションを構築して、ペイロードが突然新しいフィールドを導入し、それがたまたま既に知っているフィールドであった場合、変更せずに「自動的に」それを入力できるようにすることができますクライアント。

しかし、単純な真実は、これは実行可能ですが、ほとんど実行されていないということです。通常、セマンティクスはあいまいです。とにかく、新しいペイロードごとに毎回新しい「直感」でコーディングする必要があるため、ペイロードに直接コーディングして、それで完了することもできます。

ただし、特に HATEOS に関して重要なことは、データをサーバーに「強制」しないことです。サーバーは、特にフォームを提供している場合は、必要なものを伝えます。

したがって、思考プロセスは、「ああ、送り状が必要な場合、現在、彼らは名前、住所、注文番号が必要であり、URL エンコードが必要であり、http://exampleに送信する必要があることがわかりました」ではありません。 .com/shipping_invoice . だから私はいつも送信するだけです: 名前 + "&" + 住所 + "&" + 注文番号 毎回http://example.com/shipping_invoice . 簡単!".

むしろ、あなたがやりたいことは、「彼らが名前、住所、注文番号を求めているのがわかります。だから私がすることは、各要求に対してフォームを読むことです。彼らがどのフィールドを必要としているかを毎回確認します。もし彼らが名前が必要な場合は名前を付けます. 住所が必要な場合はアドレスを付けます. 注文番号が必要な場合は注文番号を付けます. また、事前に入力されたフィールド（または「非表示」フィールド）がある場合. 、それらも返送します。フォーム タグのアクション フィールドから取得した URL に、私がサポートしていると仮定して、要求されたエンコーディングで送信します。".

前者の場合、毎回そのペイロードが必要であると想定していることがわかります。URL をハードコーディングしている場合と同様です。一方、2 番目の場合は、名前と住所が冗長であると判断した可能性があるため、それ以上要求することはありません。おそらく、まだサポートされていない可能性のある新しい機能のために、いくつかの優れたデフォルトが追加されたのでしょう。エンコーディングをマルチパートに変更したのでしょうか。または、エンドポイント URL を変更しました。知るか。

クライアントをコーディングするときに知っていることしか送信できませんよね? 彼らが物事を変えれば、あなたはできることしかできません。フィールドを追加する場合は、必要のないフィールドを追加してください。しかし、彼らがインターフェイスを壊すと、ちょっと、彼らはインターフェイスを壊し、あなたはエラーを記録するようになります. そこでできることはあまりありません。

しかし、HATEOS の部分を活用すればするほど、より柔軟に利用できるようになります。フォームに入力し、リダイレクトを適切に追跡し、エンコーディングとメディアの種類に注意を払うことで、クライアントはより柔軟になります。

結局、ほとんどの人はクライアントでそれをしません。彼らは、バックエンドが重要なほど急速に変更されていないか、またはそのような変更が発生した場合のダウンタイムがクライアントを修正するまで許容されると想定しているため、単純であるため、全体をハードコーディングします。より一般的には、特に内部システムでは、開発者から「XYZ API を変更していました。3 月 1 日に公開されます。クライアントを更新し、統合テスト中にリリース チームと調整してください。kthx」というメールを受け取るだけです。

それが現実です。これは、そうすべきではない、またはサーバーをよりスマートなクライアントにとってより使いやすくするべきではないという意味ではありません。すべてが良いRESTベースのシステムを無効にしないと思い込んでいる悪いクライアントを思い出してください。これらのシステムは、ひどいクライアントでも問題なく機能します。wget ftw、え？

于 2012-02-24T18:53:22.993 に答える