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