問題タブ [hateoas]

クエリ パラメータを使用して RESTful 検索 URI を設計したいと考えています。たとえば、次の URI はすべてのユーザーのリストを返します。

GET /ユーザー

そして、姓が「Harvey」の最初の 25 ユーザー:

GET /users?surname=Harvey&maxResults=25

ハイパーメディアを使用して、「/users」リソースで許可されているクエリ パラメータを説明するにはどうすればよいですか? 新しいGoogle Tasks APIでは、リファレンス ガイドにすべてのクエリ パラメータが記載されているだけであることに気付きました。リストを文書化しますが、HATEOAS でもやりたいと思います。

前もって感謝します！

私はRESTfulアーキテクチャの信条をかなりよく理解していると思いますが、まだそこにはいません。

私が理解できない部分は、クライアントが各リソースで使用可能なHTTPメソッドをどのように認識できるかということです。プロセスを続行するためにアプリケーションフローで特定のアクションが必要な場合はどうでしょうか。

簡略化した例：

クライアントがRESTAPIに簡単な注文をしたと仮定します。

クライアントは、http：//api.mycompany.com/ordersに投稿リクエストを行います。

ペイロードのリクエスト

リクエストが成功したと仮定します

応答ペイロード

ハイパーメディアの制約を正しく理解していれば、対応するリソースを提供し、クライアントはそこからどこに行くかを選択できます。

上記の例では、rel = "order"のリンクは、GET、PUT、またはDELETEリクエストである可能性があります。rel = "invoice"のリンクは、GETリクエストに制限されています。rel = "payment"のリンクは、 POSTリクエストのみを受け入れます。

クライアントはこれをどのように知っていますか？前述のリソースの1つにOPTIONSリクエストを送信すると、使用可能なメソッドが提供されるはずですが、それがこの種のシナリオを処理する標準的な方法であるかどうかはわかりません。

どんな助けでも大歓迎です。

HATEOASをフォローしていて、XMLでハイパーテキストを使用しているとしましょう。このようなもの：

/ customer / 32

/ address / 4324

JAXBに類似した、またはJAXBの拡張機能で、顧客のマーシャリングを解除し、その顧客のプロパティとしてアドレスを自動的にクエリしてマーシャリング解除できるライブラリはありますcustomer.getAddress().getStreet()か？そうでない場合、クライアント側のキャッシングに役立つこれへの良いアプローチは何ですか？

JSON表現に基づいてRESTfulAPIを設計しています。HATEOASに準拠するために、私はリソース間のリンクを広範囲に使用しています。したがって、ATOMリンクと非常によく似た方法でリンクをシリアル化するために、この提案に従いました。

今、私は時々正しいリンク関係タイプを識別するのに問題があります。リソースにそれ自体へのリンクが含まれている場合、そのself関係は明らかです。リソースがサブリソースのコレクションおよび集約である場合、または関連リソースへの多くのリンクが含まれている場合は、より複雑になります。

例としてブログ投稿を取り上げ、ブログ投稿のスナップショットを返すリソースを考えてください。これには、このブログ投稿の作成者、タグ、コメントが含まれます。明らかに、このリソースには多くのサブリソースが含まれており、もちろんそれらへの個別のリンクも提供する必要があります。

サンプルリソース：

では、特定のリンクに適切な関係は何ですか？のような関係タイプがあることは知っていますがtag、すべてのリソースが既存の関係タイプと一致するわけではありません。または、作成self者/タグ/コメントを参照するときに使用しても問題ありません。これは、JSON（サブ）オブジェクトを囲むコンテキストに関連しているためです。セマンティックエンティティselfは何を指しているのですか？

RFC5988は次のように述べています。

リンクのコンテキストは、表示される場所に応じて、フィードIRIまたはエントリIDのいずれかになります。

これをJSONの観点からどのように解釈できますか？それぞれの新しいオブジェクト{…}は新しいコンテキストですか？

ありがとう！

HATEOASを使用して Spring MVC 3.x RESTful サービスを実装する正しい方法に苦労しています。次の制約を考慮してください。

• ドメイン エンティティが web/rest 構造で汚染されるのは望ましくありません。
• コントローラーがビュー コンストラクトで汚染されるのは望ましくありません。
• 複数のビューをサポートしたい。

現在、私はHATEOASなしでMVCアプリをうまくまとめています。ドメイン エンティティは、ビューや Web/REST の概念が組み込まれていない純粋な POJO です。例えば：

私のコントローラーもシンプルです。それらはルーティングとステータスを提供し、Spring のビュー解決フレームワークに委譲します。私のアプリケーションは JSON、XML、および HTML をサポートしていますが、ドメイン エンティティまたはコントローラーにビュー情報が埋め込まれていないことに注意してください。

だから、今私の問題 - HATEOAS をサポートするクリーンな方法がわかりません。これが例です。クライアントが JSON 形式のユーザーを要求すると、次のようになります。

また、HATEOAS をサポートする場合、クライアントがオブジェクトの更新、削除などに使用できる単純な「自己」リンクを JSON に含めたいとします。また、ユーザーの友達リストを取得する方法を示す「友達」リンクがある場合もあります。

どういうわけか、オブジェクトにリンクを付けたいと思っています。コントローラーはすべて正しい URL を知っているため、これを行うのに適切な場所はコントローラー層だと思います。さらに、私は複数のビューをサポートしているので、Spring のビュー解決フレームワークで JSON/XML に変換する前に、コントローラーでドメイン エンティティを何らかの形で装飾するのが正しいと思います。これを行う 1 つの方法は、問題の POJO を、リンクのリストを含む汎用の Resource クラスでラップすることです。必要な形式に変換するには、ビューを微調整する必要がありますが、実行可能です。残念ながら、ネストされたリソースをこの方法でラップすることはできませんでした。頭に浮かぶ他のことには、ModelAndView へのリンクの追加、および生成された JSON/XML などにリンクを詰め込むための Spring のすぐに使えるビュー リゾルバーのそれぞれのカスタマイズが含まれます。私がしないこと 必要なのは、JSON/XML などを常に手作りすることです。開発中に出入りするさまざまなリンクに対応します。

考え？

私は、RestEasy2.2.2を使用してTomcat7にデプロイするJAX-RSWebサービスの開発に取り組んでいます。WebサービスはJSONを（Jackson経由で）クライアントに返します。これまでは機能していましたが、クライアントに送信する必要のある動的リンクを構築する方法がわかりません。

次のことが頭に浮かびます。

1-ルートオブジェクト（それ自体に他のオブジェクトが含まれ、合計3レベル）のディープコピーを作成し、リンクを表すStringプロパティを変更して、この新しいオブジェクトを返します。

懸念事項：パフォーマンス、ディープコピーの実装を正しくする

2-リクエストごとにオブジェクトを変更して返します

懸念事項：並行性の問題（これが可能かどうかさえわかりません）

3-新しいルートオブジェクトを作成し、「メインオブジェクト」を繰り返し処理し、必要に応じて変更/追加します

懸念事項：（1）と同様。基本的に、これはコピーコンストラクタとオブジェクトのcloning（）の実装です。

私が見つけた唯一の例（「JAX-RSリソースクラス」セクションまでスクロールダウン）は、オプション3を実装しているようです。ただし、間違っていない場合は、オプション2のように動作します（オブジェクトを変更してコレクションに追加します）。 ）そして、並行性の問題がどのように処理されるのかわかりません。

ご指導、ご協力、ご意見をよろしくお願いいたします。

私はRESTの発見可能性に関連する概念を明確にしようとしています。つまり、RESTfulサービスのHATEOAS制約を満たすかどうかは、URIが発見可能であり、文書化されていないため、URIを変更できることを意味します。

これは、クールなURIの概念に従わないようです。URIが変更されないという事実です。また、Web自体のモデル（RESTは基本的に完全に適合するはずです）とは多少不一致です-URLはブックマーク可能であり、変更されることはありません。また、URLを習得すると、直接アクセスして実行できます。ルートを調べて毎回発見する必要はありません。

これに関するフィードバックは大歓迎です。

WebサービスのRESTfulAPIを構築しているときに、たとえば、クライアントにリンク関係を提供しようとしています（これはGETエントリポイントが返すものです）。

クライアントが新しい記事を投稿するには、クエリパラメータとしてでPOSTリクエスト/post-new-articleを送信する必要があることを理解することを期待しています。"text"

しかし、私はドキュメントで何も述べていませんでした"POST"し、私が期待しているHTTPクエリパラメータを彼に伝えませんでした。この情報をどこでどのように提供すればよいですか？それに関する事実上の標準/慣習はありますか？

次のようなエンドポイントを介して検出可能なリソースを持つ RESTful サービスがあるとします。

リクエスト：

応答：

そして、この応答で、クライアントはハイパーメディア リンクの 1 つをたどることができます。

リクエスト：

応答：

最初の回答はあまり頻繁に変更されず (例: 何ヶ月も)、2 番目の回答は少し頻繁に変更される場合があります (例: 毎月程度)。この種のシナリオに適した HTTP キャッシュ戦略は何ですか。日付別、クライアント ETag 比較、その他の何か?

編集: データが 1 日程度古い場合は問題ありません。それ以上はおそらく問題になるでしょう。

私は、Webサービスを介して（Java）バックエンドと通信するリッチインターネットWebアプリケーションを開発中です。Flex/FlashとGWT/Javascriptの両方でユーザーインターフェイスのプロトタイプを作成しましたが、これらのRIAプラットフォームはRPCスタイルのバックエンド通信方式（Flexの場合はAMF、GWTの場合はGWT-RPC）を好む傾向があることに気付きました。

私の場合、サーバーは、私が作成していない他のクライアントにもWebサービスを提供する必要があります。このため、私は標準ベースのWebサービス（SOAPやRESTなど）に傾倒しています。RIAは、他の人に提供しているのと同じWebサービスを使用する必要があると確信しています。私が経験から精通しているRPCスタイルをモデル化しているため、SOAPを「取得」します。私はRESTを初めて使用しますが、CXF/Jacksonを使用してRESTバックエンドのプロトタイプを作成しました。ただし、現時点では、REST APIは依然としてRPCスタイルのAPIのように感じられます。これは、HATEOASのアイデアに頭を悩ませているためだと思います。

Roy T. Fieldingsの役立つブログ投稿を約10回読んだことがあり、光が見え始めていると思います。たとえば、リソースとともにさまざまな状態遷移へのリンクを含めると、クライアントとサーバー間の結合の量を実際に減らすことができることは明らかです。私のクライアントは、その時点で表示されているエンティティで実行できる法的操作へのアクセスをユーザーに提供するボタンをレンダリングするだけで済みます。

しかし、RIAとそのサーバーアプリケーション間の緩い結合は重要ですか？

その性質上、RIAはサーバーデータモデルと非常に緊密に結合されています。箱から出して、彼らは多くのことを前提としています。緩い結合は設計目標ではないため、RPCスタイルのアプリケーションプロトコルも好むのはそのためだと思います。しかし、HATEOASを真剣に受け止めれば、実行可能なデータモデルと操作についてほとんど想定しない、はるかに一般的なRIAクライアントを作成できることに気づき始めています。これにより、バックエンドの変更を通じてクライアントを維持するための労力を減らすことができますが、これは理にかなっていますか？メリットはコストを上回りますか？

ps-2つの詳細-このアプリケーションには、非常に複雑で、深くネストされたデータモデルがあります。また、100％純粋なREST Webアプリではないと誰かが言っても、私はそれほど気にすることはできませんでした。