Question

我有一个rest API，用于管理键到值的简单映射。

例如，GET请求可能返回以下内容：

 {
    "keyA": "valueA",
    "keyB": "valueB"
 }

在请求正文中有一个PUT端点用新映射替换映射。例如，可以将地图替换为新地图：

 {
    "keyC": "valueC"
 }

这将删除键“ keyA”和“ keyB”，并添加“ keyC”。我们正在讨论的问题是，是否应允许PUT请求发送一个空的映射{}来完全清除该映射，以使它没有剩余的键。应该阻止它吗？这是否遵循REST约定？

Answer 1

这不是针对REST的问题，而是实际上针对HTTP作为遵循REST体系结构方法的应用程序使用的默认传输协议。根据{{3}}服务器

应该验证PUT表示与服务器对目标资源的任何约束一致，这些约束不能由PUT更改，也不会由PUT更改。

...

当PUT表示与目标资源不一致时，源服务器应通过转换表示或更改资源配置来使其一致，或使用包含足够信息的适当错误消息进行响应，以解释为什么该表示不适合

我承认这有点含糊，并留有足够的解释空间，但是我觉得是否要让空主体成为资源的有效状态取决于您。如果您认为它不应允许一个空的正文，则只需返回一个409 Conflict响应，指示请求失败的原因即可。

需要在此处添加进一步的说明：REST着重于媒体类型的使用。媒体类型是构成有效文档的元素的语法和语义描述。如果您将其与HTML进行比较，即会注意到它定义了何时可以将某些元素有效地放入文档中以及要使用哪种语法结构。对于此处的几乎所有文档，都应执行相同的操作。因此，媒体类型定义了对某些元素的约束，而没有约束。这里的PUT请求应对照媒体类型中定义的约束条件来验证接收到的有效负载，以确定是否出现冲突或该表示形式是否可以转换为其他媒体类型格式。

application/json就REST而言是一种非常弱的媒体类型，因为它仅定义了语法结构。它甚至不支持指向其他文档的链接。有一些扩展名，例如RFC 7231 4.3.4，它们定义了链接关系上的语义，尽管这很可能仍未定义所需元素的语义。

这就是为什么菲尔丁提到了

REST API应该花费几乎所有的描述性精力来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体定义扩展关系名称和/或启用超文本的标记类型。（application/hal+json）

Answer 2

这是否遵循REST约定？

REST对表示的描述很少，除了它们应该被标准化的事实。因此，例如，REST认为使用application/json很棒，因为它有一个标准，因此其他使用JSON的工具也可以理解您的表示形式。

还有..这就是它要说的全部内容。

一旦您在有效负载中收到带有有效JSON表示形式的PUT请求，您将执行的操作（尤其是是否应允许）是实现细节。保证您的服务器将存储它的表示形式，等等。

例如，在远程创作环境中，您的服务器实际上只是充当了一个哑数据存储，那么在 course 中，存储一个空的JSON对象是有效的。

另一方面，如果应该使用JSON表示形式来描述包含必需元素的消息，则不可以，您可能不想在此处允许使用空对象。（在那种情况下，您可能不会使用application / json，但会使用某些供应商类型。）

用于更新地图的REST API是否应允许将地图设置为空？

2 个答案: