3

在我们的项目中，可以通过 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

这种方法的一个缺点是需要两个单独的请求来获取所有数据。

您将如何解决这种不一致？

4

2 回答 2

5

这是完全正常的。让服务器用一些额外的信息来扩充表示是没有问题的。一个很好的例子是服务器向表示添加链接时。在执行 PUT 时，客户端不需要将这些链接的“副本”发送到服务器。您 GET 和 PUT 的资源表示在概念上应该是相同的，不一定逐个字节相同。

于 2011-07-16T19:28:33.023 回答
0

您没有正确使用 mimetypes。我敢打赌，您使用的是application/xml通用 mimetype，并且您的客户知道基于端点会发生什么，对吗？

处理您的问题的正确方法是使用不同的 mimetype 对同一资源进行不同的表示。例如，您可以有一个application/vnd.yourcompany.book.short+xml用于短表示和application/vnd.yourcompany.book+xml完整表示的。客户端可以使用Content-Type标头来说明他们正在发送哪一个，并使用Accept标头来说明他们想要哪个。

这并不意味着客户端必须在 POST 或 PUT 中发送简短表示。您可以将一些字段记录为可选字段，客户可以忽略它们。

于 2015-11-24T19:41:19.773 回答