On Friday, April 13, 2007, at 03:38PM, "Marc Hadley" <Marc.Hadley_at_Sun.COM> wrote:
>I'm not sure I follow all the nuances of this aspect of the
>discussion. In my view we are trying to produce an API that makes it
>easy to build RESTful services, we aren't trying to build a REST API.
Hi,
[apologies for stepping in here with just a short remark, but work will keep me another couple
of days from thoroughly digging through what has already been built and said]
I think the focus should be on (appropriately used) HTTP and not on primarily on REST. One of the benefits
a REST-Style architecture offers to an API developer is uniformity. Trying to be too generic (as in 'REST API')
reduces this benefit. One might build a framework for developing APIs for REST architectures, but when it
comes to developing the API (is this is what we do here IIUC), sticking as much to the architecture as possible
yields the greatest benefit. Every design decision we can possibly take away from the developer will make her life
easier[1].
Bottom line: I suggest squeezing the last (implicit) bit out of the HTTP specs and have it control the API design directly.
A (debatable) example would be the notion of container resources ('bags of resources') which can implicitly be
found in the definition of POST. An API that provides something like a ContainerResource class would take the
burden from the developers of defining one themselves; the API would provide more guidance and less
possibility for variation.
A nice read is Mark's abstract model of HTTP resource state[2].
Jan
[1] That is IMHO the great power of Atom as it (when assumed mandatory) narrows the design space even further.
[2]
http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt
>Marc.
>
>---
>Marc Hadley <marc.hadley at sun.com>
>CTO Office, Sun Microsystems.
>
>
>
>