社内で内部データ用のHATEOASAPIを設計していますが、リンクの検出に問題があります。誰かがこのシステムの特定の従業員に関する情報を取得するための次の一連の手順を検討してください。
- ユーザーはGETを送信して、使用可能なすべてのリソースを取得し、rel=" "
http://coredata/
としてタグ付けされたリンクを含む多数のリンクを返します。http://coredata/rels/employees
- ユーザーは最初のリクエストからrelでHREFをフォローし、(たとえば)でGETを実行します。
http://coredata/employees
この最後の呼び出しから返されたデータは、私の難問であり、さまざまな提案を聞いた状況です。それらのいくつかを次に示します。
- そのGETはすべての従業員(おそらく切り捨てられたデータを含む)を返し、クライアントはそのリストから必要な従業員を選択する責任があります。
そのGETは、クエリを実行する方法/1人の従業員を取得する方法/すべての従業員を取得する方法を説明するいくつかのURIテンプレートリンクを返します。何かのようなもの:
"_links": { "http://coredata/rels/employees#RetrieveOne": { "href": "http://coredata/employees/{id}" }, "http://coredata/rels/employees#Query": { "href": "http://coredata/employees{?login,firstName,lastName}" }, "http://coredata/rels/employees#All": { "href": "http://coredata/employees/all" } }
私はここでHATEOASに最も近いものに少し立ち往生しています。オプション1の場合、ナビゲーションのためにクライアントに毎回すべての従業員を取得させたくはありませんが、例2のURIテンプレートを使用すると、帯域外の知識がどのように導入されるかがわかります。
私の他の考えは、RetrieveOne、Query、およびAll操作をクールなURLとして使用することでしたが、これは、1つのベースURIから必要なリソースにナビゲートできるはずであるという概念に違反しているようです。
他の誰かがこれを処理するための良い方法を思いついたことがありますか?1つのリソースまたは一連のリソースを取得すると、ナビゲーションは非常に簡単になりますが、検出に使用するのは非常に難しいようです。