問題タブ [hateoas]

私はRESTAPIを設計中であり、可能な限りRESTfulであるようにしています。HATEOASをjsonの応答に組み込みたいと思います。

関連するリソースにURLを追加するのは簡単ですが、それらのリンクに使用する構造についていくつかの議論がありました。

私が見つけた多くの記事は、ATOMフィードから借用した構造を使用しています。

これはいくつかの質問を提起しました：

• なぜ配列をコンテナとして使用するのですか？私が知っているjavascript開発者によると、リンクへのアクセスは、オブジェクトのプロパティとしてのリンクを使用すると簡単になります。例えば：

  /li>

• リソースプロパティの参照を記述するための一般的なjson構造（アトムを再度適応させる以外）はありますか？（たとえば、メッセージの送信者）。

  参照はおそらくURLとして再度解決されるはずですが、単純なIDも含めるのは悪いことでしょうか？のようなもの：

  /li>

私の考えでは、HATEOASを使用すると、クライアントはAPIを使用するために多くの知識を必要としませんが、その知識を使用する可能性を排除することには消極的です（リンクを作成してプロフィール写真にアクセスするなど）。最初にユーザーを検索せずにクライアント側）。

可能な限りHATEOASの原則に沿ったRESTfulサービスを設計しています。結果として、クールなURLが利用可能なオプションを説明するリンクのリストを返すようにする方法が必要です。私はHAL-JSONを使用してデータ形式を容易にしているので、それはすべて問題ありませんが、現在、どのHTTPメソッドがこれをプルする必要があるかを検討しています。

単純なGETに固執できると確信していますが、HTTP RFCを読むと、OPTIONSがここでの法案に適合する可能性があるようです。私の唯一の懸念は太字です：

9.2オプション

OPTIONSメソッドは、Request-URIによって識別される要求/応答チェーンで使用可能な通信オプションに関する情報の要求を表します。この方法により、クライアントは、リソースアクションを暗示したり、リソース取得を開始したりすることなく、リソースに関連付けられたオプションや要件、またはサーバーの機能を決定できます。

このメソッドへの応答はキャッシュできません。

Webの標準側の経験が豊富な人に、なぜそうなるのか説明してもらえますか？私の見解では、完全にHATEOASシステムでは、この呼び出しはrelリンクをトラバースして探している操作に到達するために非常に頻繁に行われる可能性が高いため、クライアントが少なくとも短期間この結果をキャッシュすることを望んでいます。にとって。

また、クールなURLから操作を取得するためのOPTIONSと単純なGETの使用についての意見も気に入っています。

社内で内部データ用のHATEOASAPIを設計していますが、リンクの検出に問題があります。誰かがこのシステムの特定の従業員に関する情報を取得するための次の一連の手順を検討してください。

1. ユーザーはGETを送信して、使用可能なすべてのリソースを取得し、rel=" "http://coredata/としてタグ付けされたリンクを含む多数のリンクを返します。http://coredata/rels/employees
2. ユーザーは最初のリクエストからrelでHREFをフォローし、（たとえば）でGETを実行します。http://coredata/employees

この最後の呼び出しから返されたデータは、私の難問であり、さまざまな提案を聞いた状況です。それらのいくつかを次に示します。

1. そのGETはすべての従業員（おそらく切り捨てられたデータを含む）を返し、クライアントはそのリストから必要な従業員を選択する責任があります。

2. そのGETは、クエリを実行する方法/1人の従業員を取得する方法/すべての従業員を取得する方法を説明するいくつかのURIテンプレートリンクを返します。何かのようなもの：

私はここでHATEOASに最も近いものに少し立ち往生しています。オプション1の場合、ナビゲーションのためにクライアントに毎回すべての従業員を取得させたくはありませんが、例2のURIテンプレートを使用すると、帯域外の知識がどのように導入されるかがわかります。

私の他の考えは、RetrieveOne、Query、およびAll操作をクールなURLとして使用することでしたが、これは、1つのベースURIから必要なリソースにナビゲートできるはずであるという概念に違反しているようです。

他の誰かがこれを処理するための良い方法を思いついたことがありますか？1つのリソースまたは一連のリソースを取得すると、ナビゲーションは非常に簡単になりますが、検出に使用するのは非常に難しいようです。

現在構築中の WebAPI のクライアント実装を書き始めたところです。API は既に HATEOAS を採用しているので、それに応じてクライアントを作成しています。クライアントのベースとしてRestSharpを使用しています。

クライアントは、構築時に api ベース URL を渡され (" https://myapi/start ")、そこでリクエストを発行し、その後、他の利用可能なリソースの一連の uris を渡します - 承認 ( " https://myapi/ authorize ") を呼び出し、アクセス トークン (" https://myapi/tokens ") を要求して、API 上の保護されたリソースを呼び出すことを承認します。

問題は、返されたハイパーメディアの rel="" 要件について、まだ策定されている標準があるかどうかです。

私は REST API の計画の初期段階にあり、REST の HATEOAS 制約に準拠したいと考えています。しかし、JSON 形式も提供したいと思います。したがって、私の質問は、JSON でリンクとフォームを表すための規則があるかどうかです。

リンクの例を見つけましたが、これはリンクを表すかなり一般的な方法のようです。

一方、フォームを表現することは、私があまり見たことがありません。おそらく誰かが座って、これらの線に沿って何かを考え出したのではないかと考えていましたが、すべての警告を考慮しました。

これのインスピレーションは、Jon Moore が JSON はハイパーメディア API の適切な形式ではないことを示唆しているこのビデオを見ることから来ています。

http://oredev.org/2010/sessions/hypermedia-apis

ところで、本当に良い話です！

すべてのご意見をお待ちしております。

（注：URIを使用してリソースを識別するRESTサービスを想定していますが、これは厳密にはRESTの制約ではないことを認識しています）

HATEOASの私の理解から、クライアントは、最初のエントリポイントを除いて、サービスによって提供されるURI構造について何も想定すべきではありません（代わりに、サーバーによって構造化された方法で提供されたURIのみを使用する必要があります）。これは、クライアントが最新のリクエストによって指定されたURIのみを使用できることを意味しますか、それともクライアントは同じセッションからの以前のリクエストで受信したURIを追跡できますか？前者の場合、後者はどのREST制約に違反しますか？

URIを追跡する2つの例：

1. 写真表示アプリケーションでは、写真のリストをトラバースして、一部のURIをリストに保存します。次に、「モザイク」機能に移動し、保存されたURIからすべての写真をモザイクにロードします。
2. 商品のリストを閲覧して、クライアント側のショッピングカートに追加します。完了したら、Ordersリソースに新しい要素を作成し、URIで指定された順序で製品を作成します。

私は、ソフトウェアのライセンスを取得するために、しばらく前にWebアプリを開発しました。これには、顧客、アカウント、ユーザー、およびライセンスがあります。ライセンスはユーザーに割り当てられ、シリアル番号でアクティブ化されます。ライセンスは、発注書の処理の出力として作成されます。つまり、新しいライセンスをPOSTする直接的な方法はありません。

私は現在「RESTfulWebサービス」を読んでいて、それをどのようにRESTfulにするかを考えています（HATEOASも）。

ほとんどのURLは明確ですが、ライセンスにはいくつかの興味深いアクションが必要です。ライセンスの基本URLはです/licence/{licenceID}。

• 使用可能なライセンスをユーザーに割り当てます（サポートスタッフが行います）
• ユーザーからライセンスを解放します（使用可能なライセンスのプールに戻します）
• シリアル番号を使用してライセンスをアクティブ化し、代わりにキーを生成します
• ライセンスを再アクティブ化する
• ライセンスを新しい有効期限に更新します
• ライセンスを無効にします。一方向のみで、元に戻すことはできません。ライセンスはまだ存在します

現在、RESTでは標準的なメソッドしか使用できず、「割り当て」というアクションをURLに埋め込んではいけません。私が考えているのは、影響を与えたいライセンスの部分を選択することです。これは与える： -

• リスト：GET /licences/
• 得る：GET /licences/{licenceID}
• 割当：POST /licences/{licenceID}/assignee/{userID}
• リリース：DELETE /licences/{licenceID}/assignee
• 活性化：POST /licences/{licenceID}/serialNumber/{serialNumber}
• 非アクティブ化：DELETE /licences/{licenceID}/serialNumber
• 更新：POST /licences/{licenceID}/expires
• 無効にする：DELETE /licences/{licenceID}/enabled

私の質問は：-

• このURLスキームは、それを行うための「正しい」または賢明な実践的な方法ですか？
  • または、「ライセンスの割り当て」と「ライセンスのアクティブ化」のコレクションが必要です（例/assignments/{licenceId}/{userId}:)
• 私は何か基本的なものが欠けていますか（本を読み終えたときに明らかになるかもしれません）
• パラメーター（userIdおよびserialNumber）は、パスパラメーターまたはクエリパラメーターとして使用する必要がありますか？
  • {userId}はシステム上のユーザーを参照しているため、パスパラメーターになる可能性があります
  • {serialNumber}は、クライアント（Java Swing）で独自の情報（シリアル番号の中央DBはありません）から生成されます。

どうもありがとう！

私がRESTで読んだすべての記事と本は、ハイパーメディア応答に「自己」relリンクを追加することの重要性を繰り返していますが、それらはすべて理由と使用例に光を当てています。

なぜセルフリンクを追加する必要があり、それはどのように役立ちますか？

私は JAX-RS を学んでおり、応答で他の関連するアクションに URL を返すというアイデアが気に入っています。Apache TomEE JAX-RS 1.5.1 を使用すると、何らかの理由で、注入されたUriInfoインスタンスによって提供される URL が常にホスト名として「localhost」を使用します。

を追加し@Context HttpServletRequest、 と のgetLocalName値getServerNameは両方とも公開ホスト名と一致しました。したがって、この情報は、TomEE にバンドルされている CXF-RS ランタイムで利用できるはずです。なぜ使われていないのかは不明です。

以下は、テストクラスとサンプル出力です。TomEE の組み込み CXF-RS に正しいホスト名を使用させるにはどうすればよいですか? または、それが適切なアプローチでない場合、JAX-RS 応答で返すことができる URL をどのように作成すればよいでしょうか?

出力は次のとおりです。