CMIS
Roy Fielding: All of those points are rather small compared to my overall complaint that it isn’t appropriate to define a “REST” binding to a specific data model’s limitations. The whole point of REST is to avoid coupling between the client applications and whatever implementation might be behind the abstract interface provided by the server.
First, by way of disclosure, I had an opportunity to provide some input several months ago as this was being developed, and a number of changes were made based on my input. I also chatted with Al Brown last night.
I also chose to be willfully oblivious to any hype. I have no comment on any complaints that have been made along those lines.
What matters most to me is not how they derive or express this specification, but on whether the operational behavior is such that a pure HTTP client can fully participate up to the limits of the HTTP specification, and AtomPub clients can participate to the limits of the AtomPub specification. By that I mean that extensions are fine, if they are truly optional, e.g., an AtomPub client which is otherwise unaware of CMIS would be able to traverse collections, and fetch, update, and delete resources.
Based on my discussion with Al last night, I’m cautiously optimistic that this will be the case. I looked at specific instances of service documents and feeds before I came to this conclusion. Furthermore, they were open and responsive to my feedback, and I believe that their invitations for others to participate to be sincere.
Roy’s point that HTTP headers that affect the representation returned without a VARY header will poison caches is valid, and represents a bug. I’ll point out that adding such a VARY header could very well cause caches to be less effective. But, again, I view that as a simple bug, one that the TC intends to address, and one that isn’t overly surprising or a cause for concern at this early stage of standardization.
Certainly neither HTTP nor AtomPub standardize query, as such I do not see it as a problem if a new media type is introduced for this use case. Perhaps there might be a better way, and if so, it should be pursued, but otherwise a new media type is a perfectly acceptable solution.
As I’ve done with numerous other Atom extensions, I plan to work with this team to add support for CMIS to the Feed Validator.