How to deal with merged objects/resources in a web

Question

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).

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.

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?

Answer 1

@Darrel Miller:

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.

I would only add that the system should accept links to /Bill/222 and /Bill/111 as equivalent, i.e. given a user editing /Joe/999 indicating that /Bill/222 is a friend of Joe's:

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

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

This should be semantically identical to befriending /Bill/111, and indeed after issuing the above PUT, I wouldn't be surprised that when I GET it back that I see the link changed to 111.

Answer 2

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.