on Code

Web Services: XML-RPC, SOAP, and REST

A now a note on web services.

Web services and their prime role in a service oriented architecture are all the rage in IT at the moment, including GIS. I’ve talked about SOA and web services before, but I never hit on the different implementations of web services. Understanding the differences between these implementations is important in designing your own web services and consuming the web services of others.

Generally speaking, there are three web service implementations: XML-RPC, SOAP, and REST.

First, XML-RPC.

  • Remote procedure call using HTTP as the transport and XML as the encoding
  • Works over HTTP Post
  • Yuck
Lest you mistake this from an overly-objective review, let me put it quite simply: XML-RPC sucks. That’s right, I said it: it sucks. It is mind-bogglingly under-equipped for even simple tasks, and almost nobody uses it. SOAP is its successor, and it’s a lot better. Enough said.

Now let’s look at SOAP.
  • Remote procedure call using HTTP (generally) as the transport and XML as the encoding
  • Works over HTTP Post
  • Generally requires a separate toolkit
  • Tends to be complex and slow
There are some good things to say about SOAP. It uses an XML file or generates XML output called WSDL (pronounced ‘wiz-dull’) that acts somewhat as metadata, which is nice if your client IDE supports that. SOAP has internal support within the protocol for things like encryption and authentication. SOAP supports more methods of network transport, and though I’ve yet to find anybody that really cares about anything other that HTTP, you might. All in all it’s not bad, particularly if having a WSDL discovery service is important to you. You generally need a toolkit to deal with it’s complexity, but many languages and IDE’s come with SOAP toolkits built in.

People generally fault SOAP for two very legitimate things. It is mind-bogglingly complex and over-equipped for almost any task you can think of, but particularly so for the relatively simple thing you probably want to do. Its elaborate feature set means its can be a pain to deal with, and the odds of you ever needing that elaborate feature set isn’t terribly high. The second thing people fault it for is speed: it’s the single slowest way to implement a web service, hands down. Amazon, which releases its very popular web services under both SOAP and REST, say their REST services are seven times faster.

Which brings us to REST.
  • URI call through HTTP GET
  • Bound to HTTP
  • No extra toolkits required
  • Doesn’t share all of the features of SOAP
REST is not a protocol like SOAP is. REST is a pretty old way to do a new thing. Essentially you are sending arguments through the URL string (i.e. mypage.php?arg1=xxx), and the page writes back the result as XML or whatever else it is designed to spit out. As it’s bound to HTTP, any kind of encryption or authentication would be that of the web server itself. The drawback to this methodology is you don’t have all of the features of SOAP, so if you need some of those features, don’t use REST. The benefits of REST are that it’s extremely easy to build and consume REST web services, no toolkits are required, and it’s extremely fast.

To sum up:
  • Advantages of SOAP
    • Easy to consume - sometimes
    • Rigid type checking - adheres to WSDL contract
    • WSDL offers some built-in metadata
    • A number of development tools support it
  • Advantages of REST
    • Lightweight - not a lot of extra XML markup
    • Human readable results
    • Easy to build - no toolkits required
    • High performance
I don’t think you can go wrong using either SOAP or REST. When I’m building a web service in .NET, it tends to be SOAP, because it’s easier. When I’m making a web service in PHP, it tends to be REST, because it’s easier (PHP’s built in SOAP toolkit doesn’t auto-generate WSDL, and writing WSDL files is for crazy people). I don’t have a problem consuming either from whatever language I’m using.

In terms of popularity, SOAP tends to get higher marks internally in corporations, particularly those on the .NET platform, but REST seems to be more popular in the “real world” (Amazon reports its REST services receive ~80% of its web service traffic).

So, those are your three web service implementations. Of the three, stick with SOAP and REST, and use the one that makes the most sense for what you’re doing and what you’re doing it with. Happy coding.


There’s a PHP project called NuSOAP that does output WSDL given some information, but I haven’t tried it.