Kevin,
On Feb 18, 2010, at 12:02 PM, Kevin Duffey wrote:
> So maybe rather than pushing this idea of pure REST on the community, we should coin what I think you and/or Jan call an HTTP API... perhaps come up with a better name for it.. or maybe not... I honestly don't know if I would want to become a pure REST based API with what I feel are now limitations of the meaning of a RESTful API.
1.
There are benefits, IMHO, of APIs that couple client and server by the original design (URI space, payloads, requests) when compared to other form of remote communication. One of them being clarity another one being the ability to see what is going on with a browser.
However, it must be understood that the architectural properties are not those of REST-style systems. And it must also be understood what the architectural properties of those systems are. REST trades off certain properties (e.g. performance) to gain certain other properties (e.g. scalability).
It must be understood, that you might create a system that pays REST's penalties (e.g. not being optimized for performance) without achieving REST's benefits. What you bild might look cool because it's Webby and all but it might just be a shitty solution to your problem.
Make sure you cover all grounds to make informed decisions.
2.
REST's primary aim is to enable the creation of systems that have a very long lifetime (decades) and can be evolved in a decentralized fashion without the need for server owners to consult all the client owners to ask what clients might break by what change of the server.
The startup cost for achieving this is considerably high (proper media type design, proper client programming model) and the integration task you are facing might not warrant that endeavor. The lifetime might be too short, the decentralization aspect might be too small etc.
My personal opinion is that enterprise IT has a very similar problem space than the Web has. For example, it can be very costly (or impossible) to get the responsible developers in a room to discuss changes or it might just not be feasble to have those 'update days' where all the components of a system have to be updated at once in order not to break the system. I see REST as a perfect fit for the enterprise (even with the startup cost).
RESTful systems have the property that a person, faced with the task of changing a service implementation really does in no way need to consider what any client out there might be doing. As long as the following is adhered to:
- keep resource semantics stable and make URIs cool ('cool URIs don't change')
- conform to the media type specs
That is a huge advantage because you need no communication whatsoever with your client owners to change a service.
Jan
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------