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:

 
Query
     GET without any parameters should return an empty feed (in respect to
     AtomPub, section 5.2: "The returned Feed may describe all, or only a
     partial list, of the Members in a Collection.").

 
Query
     GET should support all the inputs from the CMIS query Service as optional
     HTTP Parameters.

 
The
     returned document is an Atom Feed with Entries which <continue
     describing what goes in here> ...

 
Implementations
     should take care to properly set the various HTTP headers relating to
     caching to ensure valid results reach the clients (repository specific).

 

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