如何根据 HATEOAS 约束使用 PUT 对资源创建进行建模？答案

【问题标题】：How to model creation of resources using PUT according to the HATEOAS constraint?如何根据 HATEOAS 约束使用 PUT 对资源创建进行建模？
【发布时间】：2019-09-03 16:25:14
【问题描述】：

假设我正在开发一个带有项目容器的 RESTful API：

/items

各个项目将由以下 URI 标识：

/items/{id}

描述新项目可以在 HATEOAS 约束下通过 PUT 请求创建这一事实的最佳方式是什么，即客户端指定 {id} 的位置？

PUT /items/1234

【问题讨论】：

标签： rest put hateoas

【解决方案1】：

描述新项目可以在 HATEOAS 约束下通过 PUT 请求创建这一事实的最佳方式是什么，即客户端将指定 {id} 的位置？

你会如何在网站上做到这一点？

您可能有一些提供表单的资源；并且表单将包括id，可能还有其他有趣的东西。客户将填写表格（使用语义提示来解释每个字段中属于哪些信息）。提交表单时，HTML 处理规则会将表单值编码为 application/x-www-url-formencoded 表示，这将成为目标 URL 的查询部分。服务器将检查负载，计算适当的目标 URI，并向客户端发送重定向响应。

然后客户端可以GET/PUT/POST等到服务器推荐的资源。

如果你稍微眯起眼睛，你可能会看到表单正在扮演的角色与URI Template非常相似。

所以基本草图非常简单：客户端和服务器必须就描述模板（及其语义含义）的媒体类型以及相应的处理规则达成一致。

这是一个坏消息：这有点难。在万维网中，HTML 为我们完成了吨的繁重工作。如果您的 API 还使用其资源的 html 表示，那么您可以捎带已经存在的表单。但是 HTML 有点过时了。

在 API 空间中，JSON 占据了很大的份额，并且有一些媒体类型使用它作为起点。 Sookocheff's 2014 survey 现在已经 5 岁了，但会让你对外面有什么有所了解。

【讨论】：

谢谢，形式的想法有可取之处，我会考虑的。我查看了 RFC6570 模板，我喜欢通过 Link: 和 Link-Template: 标头记录链接并使用 OPTIONS 记录可用 HTTP 方法的想法，但我想不可能在 RFC6570 URI 上发出 HTTP 请求（即 OPTIONS）模板？也许是链接模板：使用 rel = 文档的 URL（即 /rels/items/item）。