我正在实现 RESTful API，并且我不确定对于无法更改的数据的存在是否存在“社区接受”行为。例如，在我的 API 中，有一个“文件”资源，该资源在创建时包含许多在创建后无法修改的字段，例如文件的二进制数据以及与其关联的一些元数据。此外，“文件”可以具有书面描述和关联的标签。
我的问题涉及对这些“文件”资源之一进行更新。特定“文件”的 GET 将返回与该文件关联的所有元数据、描述和标签，以及文件的二进制数据。特定“文件”资源的 PUT 是否应该包含“只读”字段？我意识到它可以通过以下两种方式进行编码：a）在 PUT 数据中包含只读字段，然后验证它们与原始数据匹配（或发出错误），或者 b）忽略 PUT 数据中只读字段的存在因为它们无法更改，如果它们不匹配或丢失，则永远不会发出错误，因为逻辑会忽略它们。
看起来无论哪种方式都可以并且可以接受。忽略只读字段的第二种方法可以更紧凑，因为 API 客户端可以根据需要跳过发送只读数据；这对于那些知道自己在做什么的人来说似乎很好......
就我个人而言，这两种方式都是可以接受的……但是，如果我是你，我会选择选项 A（检查只读字段以确保它们不被更改，否则会抛出错误）。根据您的项目范围，您无法假设消费者深入了解您的 Restful WS，因为他们中的大多数人不会阅读文档或 WADL，即使他们是经验丰富的人。 :)
如果您不立即向消费者提供某些字段是只读的反馈，他们就会错误地认为您的网络服务将在不进行双重检查的情况下处理他们所做的所有更改，OR一旦他们发现“不一致”的更新，他们就会向其他人抱怨你的网络服务有问题。
如果只读字段与原始值不匹配，您可以通过两种不同的方式来解决这个问题......
- 不处理该请求。发送 409 冲突代码和具体错误消息。
- 处理请求，发送 200 OK 和一条消息，说明只读字段所做的更改将被忽略。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
