你的问题在 Stackoverlow 上有很多答案，但大多数都绕开了你问的原因，我怀疑你总是觉得它们部分不满意。
如果我们相信 Roy Fielding 的话，那么使用 HTTP/HTML 将大多数商业交互式客户端应用程序编写为 SOA RESTful/HATEOAS 是不可能的。我不能说，在其他媒介中可能是可能的。
所以实用的答案是“在文档中查找”和“用我的应用程序知识编写您的客户t ” 附带“忽略我们这样做违反菲尔丁规则的事实”。
我倾向于设计提供这种方法的 JSON 响应：
GET /account/12345 HTTP/1.1
{
"account": {
"number": "12345",
"currency": "usd",
"balance": "100.00",
"deposit": {
"href": "/account/12345/deposit",
"action": "POST"
},
"withdraw": {
"href": "/account/12345/withdraw",
"action": "POST"
},
"transfer": {
"href": "/account/12345/transfer",
"action": "POST"
},
"close": {
"href": "/account/12345/close",
"action": "DELETE"
}
}
}
...根据需要为设计添加其他属性，但这些是基础。
我相信这允许消费客户端以 RESTful 方式编写，但这样做我使用的是响应正文，菲尔丁说这不是他的本意。
我会提供这个解释单独到答案：
Fielding 说：“我对将任何基于 HTTP 的接口称为 REST API 的人数感到沮丧。” (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)。
请注意他如何如此刺耳地说“任何”基于 HTTP 的界面。
他的“讲座”中最相关的部分是：
"除了初始 URI（书签）和适合目标受众（即, 期望被任何可能使用 API 的客户端理解). 从那时起, 所有应用程序状态转换必须由客户端选择服务器提供的选项驱动, 这些选项存在于接收到的表示中或由用户对这些表示的操作暗示表示。转换可以由客户端对媒体类型和资源通信机制的知识确定（或限制），这两者都可以在运行中得到改进（例如，按需编码）。[此处的失败意味着带外信息正在推动交互而不是超文本。]"
他这么说是因为 HTTP/HTML 应用程序 URI media-type 只是“text/html”，而其中的动词在哪里？没有一个。 URI 无法告诉您使用/导航需要什么动词，因此您不能仅使用带内数据在客户端中动态构建“下一个”导航。
他解释说，他认为我们将 URI 呈现为包含“方法”的 CDATA 的一部分，或者 URI 的上下文会不言而喻地提供它，就像 FORM 元素一样。他明确反对 OpenSocialst REST API，声称它不是 RESTful。
在这里：“带有HREF属性的锚元素创建一个超文本链接，选择后，在与CDATA编码的HREF属性相对应的URI上调用检索请求（GET）。”标识符、方法和媒体类型是正交关注点——媒体类型没有赋予方法意义。相反，媒体类型告诉客户端使用什么方法（例如，锚意味着 GET）或如何确定要使用的方法（例如，表单元素说要查看方法属性）。客户端应该已经知道这些方法的含义（它们是通用的）以及如何取消引用 URI。
请注意，他说客户应该已经知道方法的含义，他并没有说客户应该已经知道它们是什么 - 这就是你问的原因你的问题。很多人都在为此苦苦挣扎，因为我们实际上并没有在大多数 SOA 环境中像这样构建我们的应用程序。
像许多工程师一样，我只是希望菲尔丁能做出澄清或重新声明，但他不仅没有这样做，他还向我们作为工程师发表了两条进一步的警告，加倍强调他的声明，说我们应该停止调用 API 的 RESTful 并接受我们正在构建 RPC。
我认为类似 JSON 元素的方法是一个合理的桥梁，但我无法回答我们使用请求正文来执行此操作的事实，而不是依赖媒体类型来暗示它。
最后，HTTP 中有一个较新的动词，称为 OPTIONS，对于给定的 URI，将返回允许的动词动作列表。我认为菲尔丁参与编写了这个 HTTP 修订版。这将允许客户端在没有被禁止的内部应用知识的情况下一般地构建 URI 导航。但这在现实世界中我能想到三个问题：
- 您必须在您的服务聚合中编写一种机制，以便对您尝试返回的每个 URI 进行调用，并且由于大量数据包含许多 URI（HAL 中的 _links），这会在您的服务中添加大量额外的“跃点”响应构建。我们可能都会抱怨这一点。
- 几乎没有任何声称是 RESTful 的 SOA 站点实际上实现了一个 OPTIONS 动词方法调用，让您无论如何都要进行此查询。
- 我们都会抱怨它在客户的处理过程中增加了“不必要的”额外调用（尤其是在电子商务领域），以及它倾向于使我们超出 SLA 要求。