[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'onetime' Service Document for reliable POST



2007/8/24, Teo Hui Ming:
> On 8/24/07, Thomas Broyer wrote:
> >
> > For the "reliable POSTs" mechanism you'd like to achieve, you might be
> > interested in POST Once Exactly (POE):
> > http://tools.ietf.org/html/draft-nottingham-http-poe-00 (there's also
> > a copy at: http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt)
> > See also: http://www.mnot.net/blog/2005/03/21/poe
>
> Thanks for the links.
>
> If I understand correctly, POE defines how clients should treat POE
> resources, but it does not define *where* clients can get POE
> resources.
>
> IOW, to use POE pattern in atompub or any application, we still need
> to define on the *where*.  What I did in [1], is to define a 'onetime'
> Service Document with its own media type
> "application/x-onetime-atomsvc+xml". Clients may retrieve this
> document to obtain 1 or more POE resource URIs.
>
> [1] http://www.teohuiming.name/blog/onetime-service

With POE, you don't need to have a distinct URI for the "Service
Document with POE support".
A POE-aware client will send a "POE: 1" header with each of its GET
requests. If it then send a GET request to a Service Document which
supports POE, the server will return the Service Document with
collections' href changed to POE resources' URIs, and lists them in
the POE-Links response-header (note that the server should also return
a "Vary: POE" response header).
If the server isn't given a POE header as part of the request, it just
sends the Service Documents with the "direct" collection URIs (i.e.
those where you can POST more than once, as defined per the AtomPub
spec).

See the very first request/response pair in section 5 (Example), this
is the Service Document retrieval. Subsequent request/response pairs
are similar to POSTing to a "POE collection" resource.

Please note that, unfortunately, POE has expired almost two years ago.
It would be cool to resurrect it and push it to "Experimental" at
least (Mark?).

-- 
Thomas Broyer