« Will Vonage Die? | Main | Abandoning SCode CAPTCHAs »
Crying Out for a RESTful Service Interface Description Language
Dave Rosenberg is frustrated with Web 2.0 apps that don’t play well together:
If you haven’t seen any of the 37 Signals stuff, it’s great. Easy to use, well-designed etc. But even they don’t offer a completely integrated suite of all of their own apps. I need Basecamp integrated with MyYahoo and Salesforce.com to really be productive. I want all my stuff on one page at one URL, in sync across multiple computers and visible on my handheld. This was the promise of portals but it remains unfulfilled. … To me the big opportunity of Web 2.0 development is the ability to create a better user experience based on features etc. Instead we are ending up with a morass of social-networking, photo-sharing redundancy. And while much of this stuff is cool and potentially usable, it’s not enough.From Frustrated by Web 2.0’s lack of multi-site integration
Referenced Thu Jun 29 2006 11:39:02 GMT-0600 (MDT)
Adam Fields picks up the thread with an observation that UNIX command line programs have a similar problem and solve it with a pipe and flags that changes the modality of the application to make it more suitable for a specific use. He makes mention of the fact that it’s more complicated due to dynamic interfaces. I had another riff on the same theme…
Web services (with SOAP) introduced a wonderful style of application integration because the standards associated with them encourage intermediation. Web services intermediaries offer all kinds of services that makes managing and integrating multiple services easier.
RESTians are fond of making fun of the myriad standards associated with Web services. I’m sympathetic. Sometimes it seems like it’s gotten way out of hand. But these standards have an aim of creating context that is sufficiently well-defined that intermediation and orchestration are not just possible, but easy.
Intermediation and orchestration are possible with HTTP, but not really easy because that well-defined context is missing. In UNIX, stdin, stdout, environmental variables, and so on are the all the context that necessary. Integrating Web 2.0 apps is more complicated.
A good first step would be a well-accepted service description language for HTTP-based Web APIs. WSDL doesn’t work in RESTian services and there’s no RESTful alternative. Moreover, most people don’t even see the need. Well, read Dave and Adam’s posts—there’s the need staring you in the face. The only way that we’ll get to a place where Web 2.0 apps are more easily integrated is when we have a service interface description language and other metadata standards for RESTful services.
Posted by windley on June 29, 2006 11:54 AM
Comment from Shinichi Tomita at June 29, 2006 6:41 PM
How about WADL ?
http://weblogs.java.net/blog/mhadley/archive/2005/05/introducing_wad.html
Comment from Phil Windley at June 29, 2006 7:25 PM
Yes, there's also WRDL and some others. What we need is a process to combine these and make them into a standard that people can depend on.
Comment from Paul James at June 30, 2006 3:57 AM
Phil, I'm one of those people who don't see a need for a RESTian description language, surely all that is needed are common data formats that we all (or some of us) agree upon? Look at HTML as the classic example, or RSS and the Atom Publishing Format as more modern examples.
Comment from Phil Windley at June 30, 2006 9:09 AM
It's not about common formats for data exchange (XML gives us that). It's about metadata formats. The current situation is as if (a) there were not standard function call syntax in Perl and (b) once people made them up, there was no standard way to describe the format they created.
Automatic tools can't be created to intermediate and orchestrate services without metadata standards, so are you also saying that you don't see any need for tools to help programmers build compoisite services?
Comment from Paul James at June 30, 2006 10:46 AM
XML is not a data format, it's a data encoding, a data format must define the semantics of the data, and with that we don't need anything else. I know that data within a HTML documents tag is the title of the document, so does my browser, and so does a screen scraper or a microformat reader.
We also already have a standard way of "calling a function" (so to speak), the HTTP methods. In the same way I can GET a HTML page, I can GET data about the current weather in San Francisco, or the last 10 posts at my favourite weblog.
Given shared data formats and standard methods of working with that data, we can interact with the "service" without needing any more information.
As for tool, they are always useful, people always need new tools to do new jobs. However if I want to consume some data from the Web, all I need it to be able to speak HTTP and to understand the common data format I want to consume. So I need two tools, a HTTP library and a library for eating the data format. If I choose a common format for my service then anyone with a library for that format can consume it.
If there is no format suitable for my data, then sure XML lets me create a new one that is, but then I'll need to educate people on how to consume that format, then maybe a description format is useful, but that's an XML thing not a REST or Web thing and XML Schema is probably a good bet.
Comment from assaf at July 1, 2006 6:41 PM
WSDL has HTTP bindings. It supports HTTP methods, can bind parameters to URLs, and have structured URLs for operations. Is that not what you're looking for?
WS-* is incredibly hard to use without the tooling. Try using Curl to make a SOAP request with WS-Addressing headers, and extract the result with the right namespace URIs. You need tooling, and tooling needs meta-data.
Now try a simple XML/HTTP service designed for ease. You can Curl a request and pipe it to something else. Or access it with a few lines of code (do a search for “Ruby ActiveResource”). You can do a lot with little code and no meta-data.
You won't see a lot of WSDL around these services, just because it's a nice to have, but not a must.
If we’re doing a parallel to Unix, the service has to be well defined in human readable form (man, html), it has to have simple input/output (stdin/stdout, http request), and the data needs to be easily accessible (text, simple XML).
I don't see WS-* vs REST as a debate about message formats and protocols, but a result of two different approaches to building software.
Leave a comment
I encourage you to leave a comment below. Your email address will not be displayed on Technometria, but allows me to communicate with you directly. Your email address won't be displayed, but will be used to compute a MicroID for your comment.