[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Query POST vs. GET
Hi folks, I have some thoughts on the Atom binding and using POST for
the query service. Query is (per the ReSTful AtomPub Binding) a Collection.
The AtomPub RFC says the following about Collections: > 5.2 Listing Collection
Members > To list the Members of
a Collection, the client sends a GET request to > the URI of a
Collection. An Atom Feed Document is returned whose > Entries contain the
IRIs of Member Resources. The returned Feed may > describe all, or only a
partial list, of the Members in a Collection. > 5.3 Creating a Resource > > * The client POSTs a
representation of the Member to the URI of the > Collection. > * If the Member
Resource was created successfully, the server responds > with a status code of
201 and a Location header that contains the IRI > of the newly created
Entry Resource... POST is specified as a create
operation. This appears to not be particularly ReSTful and is not
following AtomPub. The document being posted looks like something that
can be represented as parameters to the GET operation. It seems like the Query Collection
should support GET with the following notes:
We also have some concern about the
paging link (next/prev/first/last). Assuming we’re trying to follow
HATEOAS (Hypertext as the Engine of Application State), the state (in this
case, the query and ability to get to next page, etc.) should be captured in
Hypermedia (the links.) The current Query Resource definition has that
State split between the links and the client's ability to "remember"
what it posted last time. I recall some dialog on this occurred in the distant past,
but I think this deserves some additional discussion. I’d like to
see what others think and file an issue accordingly. Regards, -Ryan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]