Hot news is the proposal for a REST API in Java. Equally interesting is that various members of the community are asking for a simple API with none of the usual cruft.
I’m left wondering if such an approach will just leave you with all the existing http libraries and web infrastructure (servers, caches and proxies) such as Apache’s HttpClient.
It might be that the real core of doing better REST is in tools for converting from REST-based designs into code and infrastructure rather than an API per se. Could be time to go look at what DHH and Rails have been doing in this area???
Technorati Tags: design, REST, Rails
Entries (RSS)
Dan-
I think you’re on the right track: tools. As my understanding of REST has grown, one of the things that I see as a potential issue in actually applying it is the sheer number of resources that you might wind up with. Guaranteed, not every object in a design becomes a resource, but my gut tells me that there will be a lot. Trying to manage the whole lot through hand-coded efforts just doesn’t sound like a good plan to me, unless your interest is in job preservation. It seems that this area is ripe for tooling.
-tb
Good tools are important and no doubt ease the burden. But it freaks me out when people toss that out as the potential-future-solution to the problem they are busily creating today. Tools were supposed to be the answer to the complexities known as JSF and the Java WS APIs, and they are just not there. And even if they were, show me a non-Microsoft developer who doesn’t still want access to what’s underneath when it comes time to troubleshoot or work on something built by someone else.
Todd you bring up an interesting point about the large number of resources in REST implementations, I hadn’t thought of that or heard of it. That’s an interesting topic to consider…
Hi Scott,
Completely agree re: complexity and tools. There are far too many cases where we create API’s, frameworks etc with a high degree of complexity which we then attempt to paper over with tools. There’s no substitute for keeping it simple throughout the stack.
Todd’s comment about number of resources is much more the kind of issue I was considering worth attacking with tools.
Dan.