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を使用する場合、フォームとプロンプトを使用してこれを多く表現し、サービスで実行できる操作を人間が発見できるようにすることができます。

クライアントにとって同様のことができるフォーマットはありますか？

どのような入力が受け入れられるかをどのようにして知っていますか？つまり、クライアントに事前の知識がない場合、「姓」のセマンティクスをどのように定義しますか？あなたはOWLのような何かを必要とする領域に入り始めています。

クライアントがよく知られたMIMEタイプのセマンティクスを理解することを期待する方が現実的だと思います。たとえば、「text / vcard」と言ってください。

「WADL」を通じてサービスの詳細を公開できます

http://en.wikipedia.org/wiki/Web_Application_Description_Language

これはオプションであり、すべてのバックエンドRESTテクノがこれをサポートしているわけではありません。たとえば、jax-rsの「公式」Java実装であるJerseyは、それをサポートしています。たとえば、自動で生成できます。

それが使われるのを見るのは、しかし、非常にまれです。

私はそれを使っている大きなものを知りません。一般に、APIを説明するWebページがあります。

Springは、resteasyと同様に、これをある程度サポートしています。