如何处理 Web 应用程序和 RESTful API 中的合并对象/资源？答案

【问题标题】：How to deal with merged objects/resources in a web app and in a RESTful API?如何处理 Web 应用程序和 RESTful API 中的合并对象/资源？
【发布时间】：2010-07-15 09:01:33
【问题描述】：

我有一个 Web 应用程序，它有很多页面，其 URL 格式为 /object_type/object_id/，显示此对象的详细信息。我还有一个 RESTful API，返回我的对象的 JSON/XML 表示（在 /api/object_type/object_id/ 下）。（我的对象是法律和法案，但我想这个问题相当笼统）。

不时地，我发现我的两个或更多对象实际上是重复的，并且在现实世界中描述了同一个对象。可以说他们是 /Bill/111/ 和 /Bill/222/ 。在幕后，我合并了 2 个对象，留下 1 个对象（比如说 /Bill/111/ ）包含所有信息，而另一个“空”只包含对另一个对象的引用。

我的问题是，我应该如何在网络应用程序和 API 中指示合并？我不希望 /Bill/222/ 返回 404，因为我可能有外部链接指向它，我不希望它们被破坏。我应该使用 301 永久移动吗？我是否应该返回一个正常页面（状态为 200），说明该资源被检测为重复并带有指向合并资源的链接？我应该如何在 API 中处理这个问题？例如，我应该在 Bills 索引中列出 222 吗？

【问题讨论】：

标签： language-agnostic web-applications rest

【解决方案1】：

我想我会在这种情况下使用 301，并且不会在列表中包含 222。出现 301 的唯一原因是某些客户端已将 URL 加入书签。

【讨论】：

【解决方案2】：

@达雷尔·米勒：

我想我会在这种情况下使用 301，并且不会在列表中包含 222。出现 301 的唯一原因是某些客户端已将 URL 加入书签。

我只想补充一点，系统应该接受指向 /Bill/222 和 /Bill/111 的链接作为等效链接，即假设用户编辑 /Joe/999 表明 /Bill/222 是 Joe 的朋友：

PUT /Joe/999
Content-Type: vnd.xxx+xml

<name is-friend-of="/Bill/222">Joe</name>

这在语义上应该与交友 /Bill/111 相同，并且确实在发出上述 PUT 之后，当我返回它时看到链接更改为 111，我不会感到惊讶。

【讨论】：

保留这两个 URL 的唯一问题是，根据问题 14 Range w3.org/2001/tag/issues.html#httpRange-14 的解决方案，应该只有一个 URL 为单个资源返回 200。一个资源可以有多个 URI，但如果取消引用，其他 URI 应返回重定向。