[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
>
>