如何在Web应用程序和RESTful API中处理合并的对象/资源? [英] How to deal with merged objects/resources in a web app and in a RESTful API?

问题描述

我有一个Web应用程序，其中包含许多页面，这些页面的URL格式为/object_type/object_id/，显示了这些对象的详细信息.我还有一个RESTful API，返回对象的JSON/XML表示形式(在/api/object_type/object_id/下). (我的对象是法律和条例草案，但我想这个问题很笼统).

I have a web app that has lots of pages with a URL of the form /object_type/object_id/ which show this objects details. I also have a RESTful API, returning a JSON/XML representation of my objects (under /api/object_type/object_id/ ). (My objects are Laws and Bills, but I guess this question is rather generic).

我不时发现我的两个或多个对象实际上是重复的，并在现实世界中描述了相同的对象.可以说它们是/Bill/111/和/Bill/222/.在幕后，我合并了2个对象，剩下1个对象(让我们说/Bill/111/)，并保留所有信息，而另一个空"仅引用另一个.

From time to time, I discover that 2 or more of my objects are actually duplicates, and describe the same object in the real world. Lets say they were /Bill/111/ and /Bill/222/ . Behind the scenes I merge the 2 objects, leaving 1 object (lets say /Bill/111/ ) with all the information, and the other "empty" with just a reference to the other one.

我的问题是，如何在网络应用程序和API中指示合并?我不希望/Bill/222/返回404，因为我可能有外部链接指向它，我不想让它们坏掉.我应该使用永久移动的301吗?我是否应该返回一个正常页面(状态为200)，说明该资源被检测为重复项，并带有指向合并后页面的链接?我应该如何在API中处理此问题?例如，我应该在帐单"索引中列出222吗?

My question is, how should I indicate the merge in the web app and in the API? I don't want /Bill/222/ to return a 404, because I might have external links pointing to it, and I don't want them broken. Should I use a 301 Moved Permanently? Should I return a normal page (with status 200) explaining that this resource was detected as duplicate with a link to the merged one? How should I deal with this in the API? for example, should I list 222 in the Bills index?

推荐答案

在这种情况下，我认为我将使用301，并且将停止在列表中包括222. 301的唯一原因是万一某些客户端将URL添加为书签.

I think I would use a 301 for this case and would stop including 222 in the list. The only reason for the 301 is incase some client had bookmarked the URL.

这篇关于如何在Web应用程序和RESTful API中处理合并的对象/资源?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！