RE: Using Link header in HTTP 4xx response

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Teo Hui Ming wrote:
> A bookmark collection rejects duplicate bookmarks. But client may
> handle a 'duplicate bookmark' error automatically (based on
> user-defined settings, e.g. always overwrite the existing duplicate
> bookmark), if the duplicate bookmark entry's URI is given to client.
> So, this URI should appear in the error response.
> 
> Rather than placing the URI in message body and require client to
> parse the body, I was thinking about moving the URI into a HTTP Link
> header with a 'duplicate' relation:

It so happens that I am also working on an AtomPub-based bookmarking system, which works a lot like Google Bookmarks. Is yours similar to Google Bookmarks too?

First of all, I think that it should be quite rare for the client to try to POST a duplicate bookmark. If the bookmark already exists when the user initiates the bookmarking process, then the client should let the user edit the existing bookmark, instead of attempting to create a new one. The only time the client will get to the POST step is if the bookmark didn't exist at the time the client searched for it.

There is the (slight) possibility of some kind of editing conflict. But, it will be so rare that there is no reason to optimize for that case. If you get a 409 Conflict, just search for the existing bookmark in a separate request, and then do whatever conflict resolution you would normally. 

How are you marking up your bookmarks in Atom? I am currently using the Google Notebooks encoding, but I want to switch to another one that works better for maintaining an offline cache of bookmarked pages.

Regards,
Brian