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

Question

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

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

似乎它可以采用任何一种方式并且可以接受。忽略只读字段的第二种方法可以更紧凑，因为API客户端可以跳过发送只读数据（如果需要）;这对于那些知道自己在做什么的人来说似乎很有用......

Answer 1

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

如果您没有立即向消费者反馈某些字段是只读的，那么他们会错误地假设您的网络服务会在不进行双重检查的情况下处理他们所做的所有更改， OR < / strong>一旦他们发现“不一致”更新，他们会向其他人抱怨您的网络服务有问题。

如果只读字段与原始值不匹配，您可以通过两种不同方式处理此问题...

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

Answer 2

除非只读数据构成数据的重要部分（极端情况下，传输只读数据会对网络流量和响应时间产生明显影响），您应该编写服务以接受只读数据PUT中的字段并检查它们的变化。将相同的数据输入和输出更简单。

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

禁止PUT中的只读字段是一个坏主意，因为它将要求客户端剥离他们在GET中收到的字段。这要求客户端更加密切地参与您的数据和语义，而不是真正需要的。客户会认为这是一个令人头痛的问题，一个不必要的并发症，以及你加重他们负担的彻头彻尾的意思。从您的GET收到的数据，修改一个感兴趣的领域，并通过PUT发送回给您应该是客户端的一个脑死亡的简单往返。当你不需要时，不要复杂化。