[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using Link header in HTTP 4xx response
You might consider
> POST /bookmarks/
>
< HTTP/1.1 303 See Other
< Location: /bookmarks/2
303s are useful.
.. Adam
On Wed, Apr 23, 2008 at 6:28 PM, Teo Hui Ming <teohuiming.work@xxxxxxxxx> wrote:
>
> On Thu, Apr 24, 2008 at 5:04 AM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
> > 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?
>
> Mine is just for personal leisure, not yet implemented. :-) I model it
> after del.icio.us: 3 collections (bookmarks, tags, bundles), bookmark
> collection has a 'search' link to OpenSearch doc, and 'current' link
> to Subscription feed.
>
>
> > How are you marking up your bookmarks in Atom?
>
> Google Bookmark has similar input fields as del.icio.us's:
> title - entry/title[@type='text']
> notes - entry/summary
> link - entry/link[@rel='alternate']
> tags - entry/category/@term
> private flag - entry/app:control/app:draft
>
>
> > 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.
>
> any problem in existing Google Notebooks encoding?
>
>
> > 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.
>
> Another case is when client retry a POST after a network/server
> hiccup. I will consider your option.
>
> Thanks,
> --
> Teo Hui Ming
>
>