是否有使用HATEOAS发现REST服务的策略？

在使用HATEOAS约束构建REST服务时，通过链接宣传存在的资源非常容易。您GET以我的网站的根目录为基础，然后我以列出所有第一层资源的根目录文档进行响应：

{
    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类型的语义更实际；例如为人们说“文本/ vcard”。

您可以通过“ WADL”发布有关服务的详细信息

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

它是可选的，并非每个后端REST技术都支持此功能。Jersey是jax-rs的“官方” java实现，例如支持它-它可以为您自动生成。

但是，看到它的使用却很少。

我不知道有大家伙在用它。通常，您有一个描述api的网页。

Spring对此提供了一些支持，同时也使您安心。