REST vs SOAP (again) and Public UDDI Goes Away

Every once in a while I search Google news for Web services stories.
Today a couple of interesting items came up.
The first was on this recurring motif of REST vs SOAP. Only this time the author decided to talk about it in terms of the “easy” vs the “hard” way to do it.
We went around on this a bit more than a year ago and I would have to say that the obvious conclusion seems to be that you use the simple technology when it’s appropriate, and the more complex technology when you need it.
Absolutes do not apply. It isn’t possible to characterize REST as easy without asking “easy for whom?” Or “easy for what purpose?”
These debates (mine included) always reference the experience, which shows that XML over HTTP (this is not really the same as REST by the way) is used by 80% of the developers while SOAP is used by 20%.
The first time I heard about this was back in June of 2003 and for me this still represents one of the best summaries of the phenomenon: SOAP is easier for developers used to Java or C# while XML over HTTP is easier for Web developers.
One technology is not inhernetly easier than another. It depends on the application – that is why we have different tools in the toolbox. What’s easy or hard depends on what you are doing.
If you are mapping XML to a Java or C++ class, using SOAP is easier. If you are simply searching for XML elements in an XML document to transform into HTML or something else, XML over HTTP is easier.
Another interesting news item concerns the demise of the public UDDI. I remember very well when this was launched in October of 2000 at Microsoft’s Redmond campus. It was a great vision, portrayed in living video color, of a Web of self-discovering services that would assemble themselves into any combination of interactions across the Internet to serve business and consumer alike.
One of the big problems was noted at the time: the lack of any oversight on the data posted to the public UDDI. Unlike the Yellow Pages, no one was ever in charge of verifying and validating the information being posted to any of the public sites. IONA developers used to store their browser bookmarks there, for example, for later retrieval after upgrading or changing computers.
Another problem was the data model. Granted, the world lacks a unified business or industrial categorization scheme, so this isn’t entirely the fault of UDDI.
I also clearly remember, late in the day, after all the video and PowerPoint, someone from the audience raising his hand to ask the question: “Can these technologies be used inside the firewall?”
It’s hard to remember now that back in 2000 now one was thinking about using Web services inside the firewall. We were all caught up in the magic of Web services over the Internet (“the browserless Web!”), and weren’t thinking much about using UDDI for an enterprise registry/repository. However today that’s very clearly what we are left with.

6 responses to “REST vs SOAP (again) and Public UDDI Goes Away

  1. “Absolutes do not apply”. Never? 😎

  2. Seriously though …
    “It isn’t possible to characterize REST as easy without asking “easy for whom?” Or “easy for what purpose?””
    Clearly. My position is that it’s easy for you and your customers, for solving their integration problems. Does Iona still do a big telecom business? I wish I knew back in my telecom days what I know now.
    I’m also just starting some work with a bank (or something that resembles one), which I know you’re still big into, and it looks like they’re already very document oriented so a transition to REST from a mish-mash of architectural styles and technologies won’t be too hard.

  3. Hi Mark,
    Yes, thank you. Our telecom and financial services customers are very happy with our approach to Web services.
    We are the only company I know of that really implements the multi-protocol, multi-data format, and multi language capability of Web services the way they were intended to be implemented, and this works great for mission critical, enterprise integration projects and for vendor and platform neutral SOAs.
    Since you have referenced our customers I am sure you know that among them are the largest and most successful SOA deployments today on both CORBA and Web services/ESB.
    The difference between doc-oriented Web services and REST is small but significant inasmuch as it provides a standard envelope format for the message and a standard description format for the service, which makes a service request easier to process.
    The world of IT is now and will likely be a heterogeneous place for a long time, with respect not only to architetural styles but also with respect to communication protocols, data formats, programming languages, and operating systems. Good IT solutions need to embrace heterogeneity.
    However you have not really provided much of a concrete answer to the “easier for what” question since integration is a very broad topic. I am sure the REST approach is easier for certain types of integration problems, but not for other types of integration problems.
    I never argue against REST and its usefulness. It’s just that the world of IT is a a broad and complex space. The REST approach is a good fit for many requirements, but it is not the answer for everything.

  4. “However you have not really provided much of a concrete answer to the “easier for what” question since integration is a very broad topic.”
    I’d say that if you’re dealing in the exchange of documents, that REST will be easier/simpler than SOA/WS. And that’s just considering the architectural style, not the technologies one might use; even if you had to use SOAP & WSDL for the RESTful solution, it would still be easier than if you used SOAP & WSDL in the usual SOA/WS way.

  5. Hi Mark,
    Ok, that makes sense. I agree that it’s easier to exchange documents using REST.
    But how about processing them?

  6. All the client should be concerned with is getting the document in the hands of the right processor, not what the processor does with it, since to know that is to have a dependency on an implementation detail of the server.
    What this looks like in practice is that the client has, say, a document that describes an order for shoes, and also a URI which identifies a processor which fulfils shoe orders. All the client needs to do is POST that order to that URI for the order to be fulfilled.