問題タブ [hateoas]

HATEOAS の背後にある中心的なアイデアの 1 つは、クライアントが単一のエントリ ポイント URL から開始し、公開されているすべてのリソースとそれらに利用可能な状態遷移を検出できるようにすることです。それが HTML でどのように機能するか、ブラウザの背後で人間がリンクをクリックして「送信」ボタンをクリックする様子は完全に理解できますが、この原則をどのように適用すれば (運が悪いか) 対処できなかった問題に適用できるか疑問に思っています。

私は、RESTful な設計原則が論文や教育記事で提示されているのが好きです。それはすべて理にかなっています。コーヒーを GET する方法はその良い例です。慣習に従い、単純で退屈な詳細のない例を考えてみます。郵便番号と都市を見てみましょう。

問題1

郵便番号で都市を検索するための RESTful API を設計したいとしましょう。郵便番号にネストされた「都市」と呼ばれるリソースを思いついたので、GET onhttp://api.addressbook.com/zip_codes/02125/citiesは、たとえばドーチェスターとボストンを表す 2 つのレコードを含むドキュメントを返します。

私の質問は、HATEOAS を通じてそのような URL をどのように発見できるのでしょうか? で最大 40K のすべての郵便番号のインデックスを公開することはおそらく非現実的http://api.addressbook.com/zip_codesです。40K のアイテム インデックスを使用することは問題ではありませんが、この例は私が作成したものであり、はるかに大きな規模のコレクションが存在することを思い出してください。

したがって、基本的には、リンクではなくリンク テンプレートを公開したいと思います。これhttp://api.addressbook.com/zip_codes/{:zip_code}/citiesは、原則に反し、クライアントが所有する帯域外の知識に依存します。

問題 2

特定のフィルタリング機能を備えた都市インデックスを公開したいとしましょう。

• GET onhttp://api.addressbook.com/cities?name=Xは、名前が一致する都市のみを返しXます。

• GET onhttp://api.addressbook.com/cities?min_population=Yは、人口が以上の都市のみを返しYます。

もちろん、これら 2 つのフィルターは一緒に使用できますhttp://api.addressbook.com/cities?name=X&min_population=Y。

ここでは、URL だけでなく、これら 2 つの可能なクエリ オプションと、それらを組み合わせることができるという事実も公開したいと思います。これは、これらのフィルターのセマンティクスとそれらを動的 URL に結合する背後にある原則についてのクライアントの帯域外知識がなければ、まったく不可能のようです。

では、HATEOAS の背後にある原則は、このような些細な API を本当に RESTful にするのにどのように役立つのでしょうか?

私はHATEOASを明確かつ簡潔に理解しようとしていますが、WRTRESTの専門家ではありません。（私はそれを理解していると思います、このhttp://www.looah.com/source/view/2284のおかげで）。

誰かが同様に魅力的なブログ/記事WRTHATEOASを提案できますか？

私が関与している SaaS スタートアップでは、RESTful Web API と、それを使用するさまざまなプラットフォームでのいくつかのクライアント アプリの両方を構築しています。API は理解できたと思いますが、今はクライアントに目を向けています。REST について読んでいると、REST の重要な部分は Discovery であることがわかりますが、Discovery が実際に何を意味するのかについて、2 つの異なる解釈の間で多くの議論があるようです。

1. 開発者の発見: 開発者は、リソース URI、クエリ パラメーター、サポートされている HTTP メソッド、およびドキュメントを参照して API の応答を実験することで発見したその他の詳細など、大量の API の詳細をクライアントにハードコードします。このタイプの発見には、クールなリンケージと API のバージョン管理の問題が必要であり、クライアント コードと API のハード カップリングにつながります。十分に文書化された RPC のコレクションを使用する場合よりもはるかに優れているようには見えません。

2. ランタイム検出- クライアント アプリ自体は、アウト オブ バンド情報をほとんどまたはまったく使用せずに、必要なものをすべて把握できます (おそらく、API が扱うメディア タイプの知識のみ)。リンクはホットになる可能性があります。しかし、API を非常に効率的にするには、クエリ パラメータのリンク テンプレートを大量に作成する必要があるようです。これにより、帯域外の情報が忍び寄ります。開発でここまで来ました。しかし、私は疎結合のアイデアが好きです。

ランタイム検出は REST の聖杯のようですが、そのようなクライアントを実装する方法についての貴重な議論がほとんど見られません。私が見つけたほぼすべての REST ソースは、開発者の発見を想定しているようです。ランタイム検出リソースを知っている人はいますか? ベストプラクティス？実際のコードを含む例またはライブラリ? 私は 1 つのクライアントの PHP (Zend Framework) で作業しています。もう一方は Objective-C (iOS) です。

開発者コミュニティの現在の一連のツールと知識を考えると、ランタイムの発見は現実的な目標ですか? すべての URI を不透明な方法で処理するようにクライアントを作成することはできますが、これを最も効率的に行う方法は、特に低帯域幅の接続では問題です。とにかく、URI は方程式の一部にすぎません。ランタイム コンテキストでのリンク テンプレートはどうですか? 多くの OPTIONS リクエストを行う以外に、どのメソッドがサポートされているかを伝えるのはどうですか?

仕事のためにRESTAPIに取り組んでいて、HATEOASに準拠できるように、関係を表す値だけでなく、その関係のURLも渡したいという問題に遭遇しました。

適切な解決策を思いついたと思いますが、私よりも知識のある方からの確認をお願いします。

このRESTfulJSON応答は、引き続きHATEOASの原則に準拠していますか？

では、皆さんはどう思いますか？そのフォーマットは機能しますか？

以下の@fumanchuからの提案に基づいて、これは私が今使用しようとしているフォーマットです...

指導ありがとうございます！

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

API の質問

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

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

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

クライアントの質問

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

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

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

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

私は、RESTful API 用のカスタム メディア タイプを設計している最中であり、いくつかの「標準」リンク関係のタイプとセマンティックな意味を調査して、私の設計にある程度の操縦を与えました。

問題を示すために、標準の読み取り、変更、削除メソッドを実行できるリソースがあり、GET、PUT、および DELETE の HTTP イディオムをそれぞれ使用してこれらのメソッドを実装するとします。

RFC5023で定義されているように、「編集」リンク関係 ( IANA リンク レジストリから) を合理的に (再) 使用できます。

"..."edit" の値は、href 属性の値が編集可能なメンバー エントリの IRI であることを指定します。atom:entry 内に表示される場合、href IRI を使用してリソースを取得、更新、および削除できます。そのエントリによって表される....」

このようにして、ユーザーエージェントは、「編集」関係を持つリンクがリソースの GET、PUT、および DELETE を許可することを理解できます。

ただし、ここに問題があります。リソースが GET 操作と DELETE 操作のみをサポートするようにリソースの状態が編集された場合、「編集」関係は正確ではなくなります。

精度を維持するために、i) オプション A: GET と DELETE のみをサポートする別の (複合) リンク関係を指定するか、または ii) オプション B: 可能な状態転送ごとに個別のリンクを指定し、適切なリンクを使用して示す必要があります。許可された状態遷移。後者のアプローチは正確ですが、過度に冗長に見えます。

別の方法として、(オプション C) 「編集」関係をそのままにして、精度の欠如を受け入れることもできます。つまり、リンクは GET、PUT、DELETE セマンティクスを伝達しますが、PUT を試みるユーザー エージェントは HTTP エラーに遭遇します。 405 - メソッドは許可されていません。ただし、サポートされていない状態遷移をクライアントに暗示するため、このアプローチにも満足していません。

要約すると、問題は、リンク関係の一般性と精度のバランスをとる最も賢明な方法は何かということです。

私はBackbone.jsの実験を開始し、Backbone.Modelのurlプロパティのドキュメントのドキュメントに感銘を受けました。

特に、HATEOAS/ハイパーメディアを使用してクライアントを駆動するRESTAPIを構築しています。

コレクション内のアイテムのURL自体を構築するBackboneのデフォルトの動作の有用性を確認できますが、私の場合は、解析されたデータからモデルURLを構築することをお勧めします。

これを行うためにBackboneを拡張/構築した人はいますか？たぶん、 HALのような「標準」に基づいて構築されていますか？

編集：

明確にするために、私が次のものを持っているとしましょう：

GET /orders >>

そして私は次のような注文モデルを持っています：

urlHALの「自己」参照からプロパティを自動的に引き出したいのですが。（テストされていない）次のような新しいベースモデルを作成すると思います。

考え？

フィールディングの論文（コンテンツネゴシエーション、ハイパーメディアなど）に関して本当に100％RESTfulな実際のWebサービスはありますか？RESTをよりよく理解し、Restfulieのような自動化されたクライアントから使用できるものが必要です。私がこれまでに遭遇したRESTfulであると主張されているものはすべて、実際にはRPCまたはHTTPCRUDのいずれかであるように思われます。

独自のカスタム メディア タイプ形式 (application/vnd.myapp+xml など) を作成する場合、クライアントは本文コンテンツを送信するときに、カスタム メディア タイプで送信する必要がありますか?

たとえば、注文の表現を uri に PUT します。クライアントにはリンクなどのハイパーメディア コントロールが含まれないため、コンテンツは application/vnd.myapp+xml にする必要がありますか、それとも単に xml にする必要がありますか?

ユーザーがそれを受け入れる場合、サーバーは常にカスタム メディア タイプで応答しますが (そうすべきです)、クライアントはそれを要求本文で使用する必要がありますか?