4

我仍在适应以 REST 方式做事的过程中。

在我的情况下，客户端软件将与 RESTful 服务进行交互。很少，客户端会上传其整个实体数据库（每个实体序列化为大约 5kb 的 xml 块）。

也许我错了，但正确的 RESTful 策略似乎是循环遍历每个实体并单独发布每个实体。然而，这些实体可能有数万个，而且不知何故，这么多快速射击的帖子似乎并不合乎情理。

在这种情况下，感觉就像将所有实体打包成一个大的 xml 表示会违反 RESTful 的做事方式，但它也会避免需要数千个 POST。

是否有一些标准做法来实现这一点？提前致谢！

4

4 回答 4

4

我不明白为什么不能将“实体包”视为资源。事务性写入当然可以将数据库事务视为一种资源。我承认我没有读过 Fielding 的论文，但我不明白将多个资源包装到一个表示中会如何使 REST 无效。

数据库事务做这样的事情。它们会将较小的资源包装在事务资源中。确实，他们通常这样做是为了让您可以单独发布那些仍然很大的较小资源。但是由于事务本身被认为是一种资源，我不相信为它提出一个可以作为一个 POST 请求发布的表示会使这个设计变得不那么 RESTful。

它也习惯于另一个方向。当客户端从服务器获取搜索结果时，服务器可能会将这些结果包装在一个结果资源中，这样客户端就可以只获取这一个资源，而不是几个单独的资源。

所以我想说将这些 5kb 的小资源包装在一个更大的集合资源中可以被认为是 RESTful 并且可能是您应该采用的方式。

于 2009-05-31T18:30:31.140 回答
1

只要大包装器具有有效的媒体类型，就可以将其视为单个资源。弄清楚该媒体类型将是什么是棘手的部分。

于 2009-05-31T19:33:17.443 回答
1

这里至少有两个问题阻止您使用 RESTful。

  1. 每个资源都需要通过一个 URI 来标识。对资源进行操作意味着您必须使用 HTTP 调用来调用 URI。因此，您不能在一次 HTTP 调用中调用多个资源中的多个操作。

  2. 资源由名词标识并代表实体。这意味着要插入 Employee 和 Car，您需要为每个实体调用两个不同的资源。

所以总而言之，你不能在这里采取纯粹的 RESTful 方法。但是，REST 旨在通过约定提供帮助，而不是限制您。这里最好的解决方案是让您创建一个自定义操作来满足您的需求。

或者，您可以使用 INSERT、UPDATE 和其他将不同数据块作为 XML 接收的操作来创建通用包装实体。但是，这会破坏您的其他端点，因为现在可以通过通用包装器和/Car/URI 插入 Car 记录。

在不了解您的实际需求的情况下，我建议您不要专门通过 REST 公开此功能。一旦您分解传入的集合（如果是不同的对象），您仍然可以在幕后调用您在各种控制器中的 INSERT 操作方法。

于 2009-05-31T19:42:04.337 回答
0

没有什么能阻止您在添加时创建更多资源，也就是使用 POST 将作为 X 列表的资源发布到作为 X 列表的资源。

然后，您将发送回一个 201，该 201 使用创建的所有资源的 URIS 列表创建。同样，这一切都是完全可以允许的。

您失去的是 PUT 对中介的可见性，这会阻止它们缓存或修改特定 URI 处的特定资源。尽管智能中介会出于缓存目的处理 201。

拥有一个并不会阻止您让每个创建的资源都有自己的 URI 创建后（在 POST 之后）并在这些资源上启用 PUT / DELETE。或组合。

于 2009-06-01T15:34:18.063 回答