RESTful API 设计：更新 (PUT) 中不可更改的数据是否应该是可选的？
我正在实现 RESTful API，并且我不确定对于无法更改的数据的存在的“社区接受”行为。例如，在我的 API 中，有一个“文件”资源，该资源在创建时包含许多在创建后无法修改的字段，例如文件的二进制数据以及与其关联的一些元数据。此外，“文件”可以具有书面描述和关联的标签。
我的问题涉及对这些“文件”资源之一进行更新。特定“文件”的 GET 将返回所有元数据、描述和信息。与文件关联的标签以及文件的二进制数据。特定“文件”资源的 PUT 是否应该包含“只读”字段？我意识到它可以通过以下两种方式进行编码：a）在 PUT 数据中包含只读字段，然后验证它们与原始数据匹配（或发出错误），或者 b）忽略 PUT 数据中只读字段的存在因为它们无法更改，如果它们不匹配或丢失，则永远不会发出错误，因为逻辑会忽略它们。
看起来无论哪种方式都可以并且可以接受。忽略只读字段的第二种方法可以更紧凑，因为 API 客户端可以根据需要跳过发送只读数据；这对于那些知道自己在做什么的人来说似乎很好......
I'm in the middle of implementing a RESTful API, and I am unsure about the 'community accepted' behavior for the presence of data that can not change. For example, in my API there is a 'file' resource that when created contains a number of fields that can not be modified after creation, such as the file's binary data, and some metadata associated with it. Additionally, the 'file' can have a written description, and tags associated.
My question concerns doing an update to one of these 'file' resources. A GET of a specific 'file' will return all the metadata, description & tags associated with the file, plus the file's binary data. Should a PUT of a specific 'file' resource include the 'read only' fields? I realize that it can be coded either way: a) include the read only fields in the PUT data and then verify they match the original (or issue an error), or b) ignore the presence of the read only fields in the PUT data because they can't change, never issuing an error if they don't match or are missing because the logic ignores them.
Seems like it could go either way and be acceptable. The second method of ignoring the read only fields can be more compact, because the API client can skip sending that read only data if they want; which seems good for people who know what they are doing...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，这两种方式都是可以接受的……但是，如果我是你，我会选择选项 A（检查只读字段以确保它们不被更改，否则会抛出错误）。根据您的项目范围，您无法假设消费者深入了解您的 Restful WS，因为他们中的大多数人不会阅读文档或 WADL，即使他们是经验丰富的人。 :)
如果您不立即向消费者提供某些字段是只读的反馈，他们会错误地认为您的网络服务将在不进行双重检查的情况下处理他们所做的所有更改，或者
如果只读字段与原始值不匹配，您可以通过两种不同的方式解决此问题...
Personally, both ways are acceptable.... however, if I were you, I'll opt for option A (check read-only fields to ensure they are not changed, else throw an error). Depending on the scope of your project, you cannot assume what the consumers know about your Restful WS in depth because most of them don't read documentations or WADL, even if they are the experienced ones. :)
If you don't provide immediate feedback to the consumers that certain fields are read-only, they will have a false assumption that your web service will take care all the changes they have made without double checking, OR once they find out the "inconsistent" updates, they complain to others that your web service is buggy.
You can approach this in two different ways if the read-only field doesn't match the original values...
除非只读数据占数据的很大一部分（传输只读数据对网络流量和响应时间有明显影响的极端情况），否则您应该编写服务来接受只读字段PUT 并检查它们是否有更改。让相同的数据输入和输出更加简单。
这样看：您可以在 PUT 中包含可选的只读字段，但您仍然必须/应该在服务中编写代码以检查接收到的任何只读字段是否包含预期值。无论哪种方式，您都必须编写只读检查。
禁止 PUT 中的只读字段是一个坏主意，因为这将要求客户端删除他们在 GET 中从您那里收到的字段。这要求客户比他们真正需要的更密切地参与你的数据和语义。客户会认为这是一件令人头疼的事情，是不必要的并发症，而且是你增加他们负担的彻头彻尾的手段。对于客户端来说，获取从 GET 接收到的数据，修改一个感兴趣的字段，然后使用 PUT 将其发送回给您，这应该是一个简单的往返过程。不必要的时候不要让事情复杂化。
Unless the read-only data makes up a significant portion of the data (to the extreme that transmitting the read-only data has a noticeable impact on network traffic and response times), you should write the service to accept the read only fields in the PUT and check them for changes. It's just simpler to have the same data going in and out.
Look at it this way: You could make inclusion of the read only fields optional in the PUT, but you will still have to / should write the code in the service to check that any read only fields that were received contain the expected values. You have to write the read only checking either way.
Prohibiting the read-only fields in the PUT is a bad idea because it will require the clients to strip away fields they received from you in the GET. This requires that the client get more intimately involved with your data and semantics than they really need to be. The clients will consider this a headache, an unnecessary complication, and downright mean of you to add to their burden. Taking data received from your GET, modifying one field of interest, and sending it back to you with a PUT should be a brain-dead simple round-trip for the client. Don't complicate things when you don't have to.