Bob Balaban August 20 2007 06:11:24 PMGreetings, Geeks!
I wrote a bit on this topic here in this blog a while back -->, but now I'm ready to explore it a little deeper, and I want YOUR feedback.
Why now? Why deeper? Well, my colleague Steve Nikopoulos was kind enough to lend me a book, "RESTful Web Services", by Leonard Richardson and Sam Ruby (O'Reilly Media, 2007).
Somewhere around Chapter 3, I actually got inspired to go looking for an interesting (public) RESTful Web Service. Since I'd done some writing and demo-ing about the SOAP-based Amazon.com Web Services a few years ago, and since I had heard that they'd since published some RESTful interfaces, I went looking there.
Within 15 minutes, I had registered for an access key (you use it on all the calls, so they know who's touching their server), read a bit of the online doc, and tried out my first RESTful WS call:
Go ahead, try it (go register for an ID first)! You'll get back a ton of XML describing a bunch of books written by (or narrated by, as it turns out), by an actor named Bob Balaban, and one book written by......(ta da!) ME. It was really easy, I just assembled the URL based on the doc using NotePad, then pasted it into my browser, and (as they say in France, Québec and Guadaloupe) Voilà!
So, I've been pondering the future of Web Services in Notes/Domino. I've done a lot of work with the (now I guess we can call it "traditional") SOAP-based Web Services, and, while there are some limitations there, I generally think that when you combine the technology with appropriate tools, it's pretty easy to use, and provides great RPC functionality. But it's not the best choice for everyone, all the time.
I thought I'd do a brief side-by-side pros & cons thing, then open it up for your feedback.
You can use many different tools (IBM RAD, Microsoft Visual Studio, lots more) to pull in a WSDL file and generate a SOAP client proxy class in the language of your choice. The proxy class "looks" just like the interface of the service itself. You create an instance, invoke its methods, and it (the proxy class) figures out how to serialize all the inputs into SOAP XML format, and send it over HTTP to the server hosting the service (all of this info is contained in the WSDL description, in (of course) XML format).
The other big advantage is that, when the SOAP answer comes back (and it can be complex data types), you don't have to lift a finger to parse the XML response, the proxy class does it for you. Comples data types (for both input and output) are represented as objects in your target language (e.g., Java classes), so if you're comfortable programming in that language, it looks and feels just like regular old language object oriented programming, rather simple.
The biggest drawback in this paradigm is that it's hard to do anything on the fly. You have to pre-generate the client proxy (the Web Service consumer code), and (depending on the complexity of the WSDL description of the service) you might end up with dozens of objects (representing nested complex data types, etc.) to deal with. There's also some runtime overhead inherent in all of the generated code you execute on every call, and debugging can be a big pain.
A "Service" invoked via URL certainly seems conceptually simpler. There are really only 4 "methods" to figure out, the HTTP ones: GET, PUT, POST, DELETE (there are a couple more, but they're not often used). In practice, I suspect, as with the Amazon.com example above, you really end up tacking on a bunch of URL parameters to get the service to do exactly what you want, effectively expanding the number of methods in use to, well, as many as you (or the service provider) want.
URL "commands" can easily be build on the fly (they're just strings), and virtually all programming languages these days have robust HTTP class libraries and XML parsing functionality readily available.
Plus, it's "just HTTP"! (or HTTPS, if you want to use SSL). The REST "style" implies that you address a resource of some kind with a URL/URI, specify a "method" and maybe some options, and you expect the result back (if any) in XML as well, possibly containing additional links that you might (or might not) want to follow. The Amazon.com book query at the beginning of this (now rather long) post, for example, returns some XML with embedded links, one for each discovered book, leading to the book's page on the Amazon.com site. Simple!
REST turns out to be rather AJAX-friendly, because you don't get ALL the data at once. You can pull back (if things are set up right) enough data to paint a screen (or a part thereof), and not waste time reading and caching a bunch of data you might never need.
There are, I think, actually a few drawbacks here. One is that you need to understand the data schemas involved in each Web Service (as opposed to understanding an object model in the SOAP case). You end up doing a fair amount of XML parsing to pull out the results you want from what might be a rather complex result set. The other thing about REST-style programming that concerns me is that it's gotta be true that the client is going to be making a lot of extra trips to the server, at least in cases where you want to fetch a lot of data.
Because the REST style implicitly results in XML results which contain links, you're going to (at least sometimes) be following (some of) those links. It's great that this setup yields great flexibility, it supports very dynamic UI interaction, you get the next hunk of data only when you need it, or not at all. But, more trips to the server means extra load on the server (remember: the server maintains no context from query to query, so EVERY URL must be processed from scratch every time), and extra load on the network. We worry about stuff like that.
So, for those of you who have stuck with me thus far, a couple of questions:
1) Do you buy my analysis of pros and cons?
2) I think we (Lotus) pretty much have to implement some RESTful interfaces to support AJAX style access to Domino based Web apps. Do you agree?
3) If we do that, will you use it?
4) If we don't do it (right away), what will you use instead? (Remember, we already have Java and LotusScript based WS provider/consumer functionality in v8.0)
- Comments