8

私は、モバイル クライアントと中央サーバーの間で RESTful Web サービスを利用するエンタープライズ システムに取り組んでいます。可能な限り RESTful としましょう。

私の質問は、HATEOAS (アプリケーション状態のエンジンとしてのハイパーメディア) と、HTTP 応答本文でのカスタム xml の使用に関するものです。

このシステムがパブリック クライアントによって使用されることは決してありませんが、各クライアントを個別に再構成することなく、サーバー側のリソース割り当てパターンを後で変更できるという HATEOAS のアイデアが気に入っています。スケーリングの問題により、サーバー機能を複数の物理ボックスに分散する必要があると判断した場合、問題ありません。これは、クライアント (またはクライアントからの指示を受けたサーバー) が新しいリソースを作成するときに生成される URI に反映されます。 .

私たちの事業領域は非常に具体的で珍しいものです。そのため、Web サービス全体で HTTP 応答エンティティ ボディにカスタム XML を使用したいと考えています。クライアントは、独自のアプリケーション状態を変更するときに使用できるリソースの場所を常に把握するために、xml からリソース URI を解析します。これがHATEAOSのH部分を「壊す」ことを私は知っています。

たとえば、クライアントが処理のためにトランザクションをサーバーに POST する場合、サーバーは次の xml フラグメントを 201 HTTP 応答本文に (より大きな xml ドキュメントの一部として) 含める場合があります。サーバーは、新しく作成されたトランザクション リソース自体の URI もクライアントに通知しますが、これはおそらく Location HTTP ヘッダーにのみ含まれます。 

<resulturi>http://resultserver/results/1234.xml</resulturi>

これはそんなに悪いことですか？このサービスを使用するクライアントがブラウザ ベースになる可能性はほとんどありません。URI を xml 内のプレーンテキストとして配信することに対するハイパーメディアの他の利点は何ですか?

XHTML を使用することもできると思いますが、モバイル プラットフォームのパーサーは POX の方がはるかに効率的です。

4

5 に答える 5

9

resulturi で URL を返すことによって行っていることは、事実上すでにハイパーメディアです。唯一の問題は、予測可能で文書化された方法で URL を解析できるように、応答がどのようにフォーマットされるかをクライアントに伝えるメディアタイプが必要なことです。

オプション 1: vnd.yourcompany.Resource+xml のような独自のメディア タイプを作成します。これを行うことで、メディア タイプを xml パーサーで解析できることを示していますが、会社によって定義されたいくつかの特別な規則に従います。この時点で、ハイパーメディア リンクを定義するために必要な標準を使用できます (この質問を参照)。これの優れた利点の 1 つは、6 か月以内に XML の形式に重大な変更を加える必要があると判断した場合、vnd.yourcompany.ResourceV2+xml を作成できることです。ヘッダーを古いクライアントに追加する場合、新しいクライアント アプリケーションが新しい形式を受け入れるようにすることで、古い形式と並べて新しい形式をスムーズに導入できます。

オプション 2: このオプションについては半分真剣に考えているだけですが、application/hyperxml+xml という新しいメディアタイプを推奨することを検討しています。ドキュメントは application/xml と同じルールに従いますが、ハイパーメディア用のXLinkも使用します。これにより、javascript を使用して XML ドキュメントを解析しているユーザーも、標準化された方法でハイパーメディアを利用できるようになります。

オプション 3: XHtml を使用します。あなたのパーサーが Xhtml で問題を抱えている理由がわかりませんが、あなたの言葉を信じます。

于 2009-09-09T12:38:30.503 に答える
2

基になるマークアップ言語に関係なく、RESTfulサーバーがリクエストを処理するために必要な2つの重要な情報があります。メディアタイプとURIです。特定のURIのメディアタイプを想定すると、クライアントサーバーカップリングが導入されます。たとえば、同じURIが2つの異なる種類のメディアタイプを提供することを防ぎます。

ハイパーメディア形式を設計するときのオプションはXMLだけではありません。JSONに基づいてハイパーテキスト駆動型のRESTAPIを定義するSunCloudAPIを確認してください（ただし、ハイパーリンクでメディアタイプを使用していないようです）。このアプローチから、メディアタイプとハイパーリンクを組み合わせたアプローチに移行することは難しくありません。

たとえば、次のようなLinkというJSONデータ構造を定義できます。

{
  "name":"human-readable label for link",
  "uri":"http://example.com/resources/123",
  "media_type":"application/vnd.com.example.Resource+json"
}
于 2009-09-09T14:07:35.813 に答える
2

ハイパーメディアは、HTMLや完全修飾URIさえも必要としません。メディアタイプが、応答の一部の要素を参照不可のリソースに変換するためのルールを定義している場合は、ハイパーメディアがあります。

<result>1234</result>

上記の例は、結果要素のコンテンツを逆参照する方法に関するメディアタイプのルールと組み合わせると、次のようにハイパーメディアになります。

<result>/foo/1234</result>

ベースhttpURIを付加するルールがあります。以下の例では、http文字列が参照解除可能であるという事実が暗黙的に残されている可能性があります。

<result>http://myserver.com/foo/1234</result>

ただし、それらはすべてハイパーメディアであり、その制約を満たしていますが、可能であれば、独自の新しいハイパーメディア制作ルールとタグを作成することには反対し、既存のものを再利用するだけです。最初の例では、この要素が最後の例よりもハイパーリンクされたリソースを表していることがユーザーにわかりにくくなっています。

于 2009-09-09T20:56:50.523 に答える
0

これらのハイパーリンクを手動でコーディングするのではなく、これらのハイパーリンクを作成するツールを使用することをお勧めします。相互作用指向プログラミングは、これらの相互作用 (ハイパーリンク) を作成するための優れた方法です。この技術が私たちのために働いたこのリンクに従ってくださいhttp://www.masterkube.com/hateoas_technology.html

于 2015-07-27T07:20:59.500 に答える