The Way REST Should Rather Not Go
Phil Windley writes:
The challenge for the RESTful crowd is to create a well-thought out transport alternative to SOAP. HTTP is the basis for that transport, but it’s not enough. The place to start is with service description and data binding so that RESTful Web services can enjoy the same kind of discovery that possible with SOAP.
I couldn’t disagree more — I’d much rather have the SOAP crowd drop WSDL and the data-binding crap instead of the REST folks adopting it.
Why Stefan?
I think that coding up programatic interfaces to stuff is a waste of time and building software SDKs for every language you can think of is a waste of programmers.
A good interface description makes all of that automatable. Without it, its just grunt work.
To me, programming against a strongly typed set of classes is just one of many programming models. Depending on the programming language, it may be totally inappropriate to generate code. You are much more familiar with Scheme and family than I am; in a language like that — or any other dynamic language — I fail to see what, exactly, it is that you gain from an interface description.
That doesn’t mean that there is no need for toolkits; REST folks would probably argue that if your environment provides for HTTP and XML access, that’s all the toolkit you’ll ever need.
This REST folk wouldn’t suggest that HTTP and XML are all the toolkits you need. For example, XML processing toolkits that include XPath support are great. HTTP clients that have decent caching support are great. I’d like to see a description language that is the next generation beyond HTML FORMs - something as simple, but allows control over the method, URI, message headers (including better authentication control) and message content and format. Mark Baker has outlined RDF Forms, but I haven’t looked into that much. A9.com has something called ‘Open Search’ that introduces a very terse syntax for generating URIs - a mini-service description language.