RESTful API设计：在更新（PUT）中不可更改的数据是否应该是可选的？

Question

我正在实现一个RESTful API，但对于不可更改的数据存在的'社区接受'行为感到不确定。例如，在我的API中有一个“文件”资源，创建后包含许多字段，在创建后无法修改，例如文件的二进制数据以及与其相关联的一些元数据。此外，“文件”可以有书面描述和标签。

我的问题涉及对其中一个“文件”资源进行更新。针对特定“文件”的GET将返回与该文件相关的所有元数据、描述和标签，以及文件的二进制数据。在特定“文件”的PUT中是否应包括“只读”字段？我意识到这可以编码成两种方式：a) 在PUT数据中包括只读字段，然后验证它们是否与原始数据匹配（或发出错误），或b) 忽略PUT数据中只读字段的存在，因为它们不能更改，如果它们不匹配或缺失，则从不发出错误，因为逻辑会忽略它们。

似乎可以采用任何一种方法并且都可以被接受。第二种忽略只读字段的方法可能更紧凑，因为API客户端可以跳过发送该只读数据，这对于知道自己在做什么的人来说似乎很好...

- Blake Senftner

---

仅供参考：Roy Fielding 表示 PUT 不应用于部分更新。对于部分更新，请使用 POST。PUT 用于替换给定 URL 上的资源。另请参阅：https://dev59.com/53E95IYBdhLWcg3wHqWl#2443344 和 https://dev59.com/NHE95IYBdhLWcg3wUMPW#2391954。 - Cheeso

Answer 1

就我个人而言，这两种方式都是可接受的......但是，如果我是你，我会选择选项A（检查只读字段以确保它们未被更改，否则抛出错误）。根据您的项目范围，您不能假设消费者深入了解您的Restful WS，因为即使是有经验的人，他们也大多不阅读文档或WADL。

如果您不向消费者提供即时反馈表明某些字段是只读的，他们将会错误地认为您的 Web 服务将处理他们所做的所有更改而无需再次检查，或者一旦他们发现“不一致”的更新，他们将向其他人抱怨您的 Web 服务存在漏洞。

如果只读字段与原始值不匹配，您可以采用两种不同的方式处理请求...

1. 不处理请求。发送409冲突代码和特定错误消息。
2. 处理请求，发送200 OK和一条消息，指出忽略了对只读字段所做的更改。

- limc

Answer 2

除非只读数据占据了数据的重要部分（达到传输只读数据对网络流量和响应时间产生明显影响的极端情况），否则您应该编写服务以接受PUT中的只读字段并检查它们是否更改。这样做只是为了使输入和输出数据保持一致，更加简单。

可以这样看待：您可以使包含只读字段的PUT可选，但您仍然必须/应该在服务中编写代码以检查接收到的任何只读字段是否包含预期值。无论哪种方式，都必须编写只读检查。

禁止在PUT中使用只读字段是不好的，因为这将要求客户端删除他们从GET获取的字段。这要求客户端比他们实际需要的更加深入地涉及您的数据和语义。客户端会认为这是一个麻烦，一个不必要的复杂化，并且是您增加他们负担的直接原因。从您的GET接收数据，修改感兴趣的一个字段，并通过PUT将其发送回给您，对于客户端来说应该是一个非常简单的往返操作。没有必要让事情变得复杂。

- dthorpe