HATEOASを使用してRESTサービスを発見するための戦略はありますか?
HATEOAS制約を使用してRESTサービスを構築する場合、リンクを介してリソースの存在を宣伝するのは非常に簡単です。あなたGETは私のサイトのルートにa を作成し、私はすべての第1層リソースをリストするルートドキュメントで応答します。 { users: { href: "/users" } questions { href: "/questions" } } これらのhref値の読み取り方法を理解しているクライアントは、これらの値に対してGET要求を実行し、アプリケーションで使用可能な現在のすべてのリソースを発見できます。 これは基本的なルックアップシナリオではうまく機能しますが、リソースがクエリ可能かどうかは示しません。たとえば、次のことを実行するのが妥当な場合があります。 GET /users?surname=Smith リソースの事前の知識がなくても、クライアントが一貫したクエリを形成できる十分な情報でこのクエリ機能を表現できる形式はありますか? さらに、クライアントがPOST期待された場所で特定の場所への実行を許可されていることを表現する方法はありますか。たとえば、クライアントが新しい質問リソースを作成するために以下を実行することが期待できます。 POST /questions { title: "Are there strategies for discovering REST services using HATEOAS?", body: "When building a REST service with the HATEOAS constraint, it's very..." } 人間が使用する形式としてHTMLを使用する場合、フォームとプロンプトを使用してこれを多く表現し、サービスで実行できる操作を人間が発見できるようにすることができます。 クライアントにとって同様のことができるフォーマットはありますか?