如何在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屋!