|
|
|
||
|
Building Web Services the REST Way A Busy Developer's Guide to WSDL 1.1 UDDI Morass [Craig Burton] |
Comment on this article in the Bulletin Boards. Is it just me is the W3C XML Schemas spec the worst thing ever to happen to XML? What a mess. It's hard to decide which is worse: namespaces or XSD. It would be easy to gloss over XML Schemas except for the fact that plenty of w3c specs (e.g., XQuery, SOAP) reference it. Just because the w3c sanctions an application of XML doesn't mean I have to use it. RelaxNG has made some inroads, but I am not hopeful. We're dealing with corporate might and politics. I'll stop now before I sound like a Simon St. Laurent clone. I'm moving on I tell you. If you've been following XML lately, you've probably heard of REST. Instead of sleep (which is not helpful for keeping up on XML technology), REST is an acronym for Representational State Transfer. While this doesn't sound very appetizing, REST is a way of interacting with web services without using SOAP. Although SOAP stands for "Simple Object Access Protocol," it is far from simple. SOAP is also based on W3C XML Schemas, which immediately taints the waters. Although SOAP has the backing of every software vendor that matters, it is still rare to find actual SOAP services lurking on the Internet. However, Amazon and Google both have recently made web services available to the general public, at no charge. Both SOAP and REST can leverage WSDL, Web Services Description Language. WSDL is another complex application of XML. However, the good news is that WSDL is not meant for human consumption. Rather, WSDL is useful helping development environments, e.g., Microsoft Visual Studio.NET, generate wrapper classes. Wrapper instances appear to be regular objects but invoke web services transparently. This frees programmers from the details of HTTP and XML parsers. WSDL helps web services cross the chasm into object-oriented programming languages. The bad news is that WSDL is tedious to write by hand. However, many web services platforms (e.g., .NET) generate WSDL. REST is a conceptual model of web services. SOAP is an implementation of that concept although there are those who would disagree. Having deployed and used SOAP services myself, my feeling is that if you use the right tools, SOAP is decent and usable. But good luck if you try to build SOAP clients and services from scratch. As I've said before in earlier columns, I think it's a shame that SOAP toolkits do their best to hide XML from both the users and implementers of web services. As someone who feeds the XMLEverywhere.com beast, I (obviously) happen to like XML. XML brings new and innovative solutions to the table. It's a shame to hide all the good thoughts in the XML 1.0 spec behind the plumbing. SOAP is a good of example of the "how" obfuscating the "why." Why is XML used for web services when developers are shielded from it? Wouldn't a binary format work just as well? XML allows a server written in .NET to be called by a client written with the Apache SOAP toolkit. Binary formats have been tried before and have been marred by proprietary battles. XML is definitely a big win, but should XML only benefit the infrastructure players? I don't happen to think all developers need the XML-to-Object-Oriented-Language mappings that development environments such as Visual Studio .NET provide automatically. Since the messages are XML in the first place, developers should have direct access to the XML if they so choose. With access to the XML, developers can leverage technologies such as XSLT and XPath. Furthermore, it's a bad idea to limit XML requests and responses to a remote procedure call paradigm. Remote processes should be able to pass arbitrarily complex XML messages without having to worry about whether a particular programming language will be able to handle them properly (to some extent, this is where WSDL comes in). Speaking of arbitrarily complex XML messages, many interesting web services need to consume and produce large amounts of data. Consider a web service that inserts 10,000 rows into a database. Should the data be part of the request? Does the data have to be converted to XML? Should the data be encoded as CDATA? These are tough questions. One way to transmit this data via SOAP is as a MIME attachment. The request, like an email, consists of multiple parts. Never to be outdone, Microsoft is pushing its own solution via the DIME spec. Get it together, guys! One last point regarding SOAP: conceptually, REST is more of a protocol than SOAP is. REST explicitly calls out HTTP and related technologies such as URIs. On the other hand, SOAP can be implemented on top of any messaging protocol such as message queues and SMTP. SOAP defines the message format rather than the protocol that delivers the messages. SOAP is more aptly titled SOAMS (Simple Object Access Message Specification). I think this has significant merits such as opening the door to high-performance servers that run inside the firewall in situations where HTTP-based application servers incur excessive overhead. REST is a vehicle on which XML can finally return to the fore when leveraging and implementing web services. Many programmers have successfully sent XML messages to web services using only Java, HTTP, and the DOM. This is another perfectly valid implementation of REST. To date, more programmers have probably used REST than SOAP. But as Apache Jakarta and .NET take hold, that statistic will certainly change. Unfortunately, XML will continue to be lost behind the sofa cushions. Could it be, that this is because XML has become unnecessarily complicated by things like namespaces and Schemas? Woe is XML. I need some sleep. Comment on this article in the Bulletin Boards. |
