REST - GET 返回与 POST/PUT 不同的结果
在我们的项目中，可以通过 POST 或 PUT 请求发送书籍结构（XML、JSON 等）来添加书籍。例如，在 XML 中，书籍结构如下所示（简化）：
<book>
<title>My Book</title>
<author>John Q.</author>
</book>
当这本书插入我们的后端数据库时，会自动添加一些自动生成的属性，例如创建日期、提交该书的用户 ID、标识符，...
通过 GET 检索图书时，这些附加属性将包含在图书定义中：
<book>
<title>My Book</title>
<author>John Q.</author>
<info>
<creation_date>2011...</creation_data>
<user_id>48</user_id>
<identifier>my_book_john_q</identifier>
</info>
</book>
这基本上意味着新的/编辑的图书（= 从客户端到服务器）的 XML 方案与检索到的图书不同（=从服务器到客户端）。这让事情变得混乱。
一种可能性是使这些附加属性在不同的 URI 中可用，例如：
http://server/books/:id/ -> returns the short version
http://server/books/:id/information/ -> returns the generated properties
这种方法的缺点是需要两个单独的请求才能获取所有数据。
您将如何解决这种不一致？
In our project, a book can be added by sending the book structure (in XML, JSON, ..) via a POST or PUT request. For example, in XML, the book structure looks like this (simplified):
<book>
<title>My Book</title>
<author>John Q.</author>
</book>
When this book is inserted in our backend database, some auto-generated properties are automatically added, such as the creation date, the user id who submitted the book, an identifier, ...
When the book is retrieved through a GET, these additional properties are included in the book definition:
<book>
<title>My Book</title>
<author>John Q.</author>
<info>
<creation_date>2011...</creation_data>
<user_id>48</user_id>
<identifier>my_book_john_q</identifier>
</info>
</book>
This basically means that the XML scheme of a new/edited book (= from client to server) is different than a retrieved book (= from server to client). This makes things confusing.
A possiblity is to make these additional properties available in a different URI, for example:
http://server/books/:id/ -> returns the short version
http://server/books/:id/information/ -> returns the generated properties
A downside of this approach is that two separate requests are needed to have all data.
How would you solve this inconsistency?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是完全正常的。让服务器用一些附加信息来增强表示是没有问题的。一个很好的例子是服务器向表示添加链接。执行 PUT 时，客户端不需要将这些链接的“副本”发送到服务器。 GET 和 PUT 的资源表示在概念上应该相同，不一定逐字节相同。
This is perfectly normal. There is no problem having the server augment the representation with some additional information. A good example of this is when the server adds links to the representation. There is no requirement for the client to send "copies" of those links to the server when doing a PUT. The resource representations that you GET and PUT should be conceptually the same, not necessarily byte for byte identical.
您没有正确使用 mimetypes。我敢打赌您正在使用
application/xml通用 mimetype，并且您的客户知道根据端点会发生什么，对吗？处理问题的正确方法是使用不同的 mimetypes 对同一资源使用不同的表示形式。例如，您可以使用
application/vnd.yourcompany.book.short+xml作为简短表示，使用application/vnd.yourcompany.book+xml作为完整表示表示。客户端可以使用Content-Type标头说明他们要发送哪一个，并使用Accept标头说明他们想要发送哪一个。这并不意味着客户端必须在 POST 或 PUT 中发送简短表示。您可以将某些字段记录为可选字段，并且客户可以忽略它们。
You're not using mimetypes correctly. I bet you're using an
application/xmlgeneric mimetype and your clients know what to expect based on the endpoint, right?The proper way to deal with your problem would be having different representations for the same resource, with different mimetypes. For instance, you can have a
application/vnd.yourcompany.book.short+xmlfor the short representation, andapplication/vnd.yourcompany.book+xmlfor the complete representation. Clients can use theContent-Typeheader to say which one they are sending, and theAcceptheader to say which one they want.This doesn't mean the clients must send the short representation in the POST or PUT. You can document some fields as optional and it's perfectly fine for the clients to omit them.