About the Author

author photo

Adam Trachtenberg is the Director of the LinkedIn Developer Network, where he oversees developer relations and marketing for the LinkedIn Platform. Before LinkedIn, Adam worked at eBay in platform product management and marketing. Even earlier, he co-founded Student.Com and TVGrid.com. Adam is the author of PHP Cookbook and Upgrading to PHP 5. He lives in San Francisco.

See All Posts by This Author


feature photo

Sam and Leonard ponder the differences among them. Here’s the deal:

  3. SOAP == HTTP POST, with interop issues

When I’m talking to people about web services, and I hear them use various terms, this is what I feel they’re talking about most of the time.


REST almost always indicates HTTP GET with a query string. The results are probably XML, but lately they could also be JSON.

No other HTTP verbs are used (especially PUT and DELETE), and it’s highly likely that all requests are routed through the same URI.

For example:



Nobody uses this term. However, there are some web services that, while not “true REST,” use more than HTTP GET. I place them in this category.

These likely exist because the service allows you to submit a large quantity of data that is not human readable, so it does not make sense to place as part of a query string. Blobs of HTML and pictures come to mind.

For example, the eBay “XML API”. You can submit items over eBay web services. Since the item description is pure HTML, it exceeded the maximum query string length our web server would accept at the time.

Thus, the eBay XML API was invented: you HTTP POST an XML document, we return an XML document.

Again, like REST, there’s no concept of resources. Everything goes through the same URI. The action is indicated either as part of the query string or in POST body. (Or both, as in the eBay case.)


SOAP is identical to HTTP+POX, except that you’re required to use XML Namespaces and XML Schema.

You are also going to have interop issues when trying to generate the SOAP envelope to send or parse the SOAP envelope that’s returned.

XML Namespaces and XML Schema are minor headaches, but people are willing to deal with them. People understand that, in theory, namespaces are good, even if XML Namespaces are a little funky.

XML Schema can be confusing. However, it does allow you to validate the response, which most people find to be somewhat useful. The fact that XML Schema may not be the best way to describe XML data is a different issue.

If SOAP merely had these two issues, people would work through it. The real problem with SOAP is that the specification is so confusing, people can’t build interoperable clients and servers. This drives people mad.

People know how to generate arbitrary XML (it’s just text after all) and send a HTTP POST request. They also know how to parse XML, particularly when they know ahead of time what they should expect. (That’s why PHP 5’s SimpleXML extension is a great web services client.)

What they cannot do is decipher a WSDL file to determine what crazy combination of XML the server is expecting (especially when the server is not following the standard). And, assuming they can get through that, they cannot figure out how to repeatedly hammer their SOAP client into producing the magical combination of XML necessary to placate the SOAP server.

That’s the difference between HTTP+POX and SOAP.

It’s not the complexity. Well, it’s not complexity in terms of needing to build up a large document. It’s complexity in terms of trying to understand the hundreds of pages of XML specifications to generate the request and not having good examples of working XML documents to crib off of.

As to whether the message name should go in the URI? Nobody cares.

There Are 9 Responses So Far. »

  1. Ok, that first one definitely isn’t REST: it’s HTTP+POX. Anyway, REST uses the gamut of HTTP, not just GET and isn’t just some HTTP based RPC mechanism (which the use of some parameter like “action”, “do” or so on would indicate). Whatever gave you that idea?

  2. I’m still digesting what you say about SOAP but I gotta disagree with those definitions of REST and HTTP+POX. (I don’t know whether you hold these opinions or are just reporting what others say when you discuss the matter.) They’re fairly common definitions and are remarkably close to what I used to think, so I think it’s worth taking them on.

    Most of the web services you describe as REST are in fact REST, because a lot of public web services only let you fetch data. They use GET in a RESTful way because all their URIs are safe. But if a service lets you change the dataset it needs to use the other HTTP actions (PUT, DELETE, and POST, the latter of which still confuses me) for that. The best way to do this is to structure the URIs into resources, so that if you want to get the weblog entry at URI “/weblog/posts/100”, you send a GET request to that URI, and if you want to delete that entry you send a DELETE request to the same URI.

    So the Amazon E-Commerce Service is almost entirely REST. It’s full of URI query-string options for searching and getting info from the Amazon product database,. Any query you can construct from the options describes a resource (a particular slice of the database) and GETting it gives you an XML depiction of that resource. But it also exposes some options called CartAdd, CartClear, etc. which store data in your shopping cart on the server side. This violates REST.

    GET is for getting resources, and using it to make changes is dangerous. You may remember the flap that resulted when Google released a browser-side cache that followed links. It followed links like “/weblog/delete?id=100” and triggered actions the user hadn’t requested. “Cart” can be considered a resource that you can add, modify, delete, etc. but “CartAdd” is an operation. And in fact you’ll see people saying that AECS is not REST for this reason.

    Near as I can tell HTTP+POX was invented by REST eggheads to shift off a bunch of services that didn’t meet the REST criteria, like the del.icio.us API, the Flickr API, the non-RESTful part of AWS, and so on. But since the term was coined by REST fanatics as a wall around REST, there’s no clear line of demarcation on the other side.

    HTTP+POX services and SOAP services both have rules about what XML documents you can send under what circumstances. You could have a pathological service that was more idiosyncratic than SOAP in the XML it accepted. I’d say that would be worse than SOAP, and I wouldn’t want to call it HTTP+POX because then SOAP would be HTTP+POX too. That’s why I’m looking for another way to make the distinction. There might be no sharp distinction at all, just a gradient that includes SOAP near the far end.

    Send me and Sam email if you’d like to continue this discussion and help us with the definitions.

  3. Hello Keith and Leonard —

    I gotta run to work, so this answer is going to be short, but I guess I should have be more clear in my post. This is not what *I* define as REST, HTTP+POX, and SOAP, or believe the “correct” definitions are.

    However, in my opinion, based on talking up eBay web services at many places for the past 2.5 years, if you went to a couple of web conferences and polled the attendees on their definitions of the terms, the results would be what I describe above.

    I will post more when I get more free time later today, as I am interested in continuing this discussion.

  4. I would just like to chime in to agree with Keith and Leonard. REST incorporates all of the HTTP verbs.

    A quick google of HTTP REST nets me quite a few pages that involve the words POST, PUT and DELETE, so I am inclined to think that the people writing about REST web APIs disagree with you :)

    And again, I think alot of the confusion is that eBay web services by nature are read only, making it seem like all “REST” interfaces only use GET and huge fat query strings. That said, I must argue that REST interfaces are a very fuzzy architectural notion, in much the same way that MVC or client/server architectures are ideas and not specifications. There is no spec for what verbs a REST interface must represent!

  5. Hsiu-Fan —

    There are multiple sites that describe REST using POST, PUT, and DELETE, but I find very few (if any) major sites that deploy “REST Web services” using POST, PUT, and DELETE. Can you name some?

    Leonard listed S3 and GData. Those are relatively new and GData is based on Atom, so it’s not as if Google made that up on their own.

    Also, eBay web services are *far* from read only! We have allowed read and write operations since 2001! Over 50% of eBay item listings come through web services.

  6. I stand corrected on the ebay front :) I guess I never actually looked

    That said, perhaps the lack of PUT/DELETE is caused by the lack of browser support? (And they’ve been kind of the hidden stepchildren of the HTTP verbs…) I definitely do agree with your point and want to apologize for jumping on you. It just seemed like you were stating your definition for “what is REST” as opposed to “how is REST implemented”.

  7. I was surprised by the initial definition of REST given at the beginning of this discussion. I don’t believe that Roy Thomas Fielding (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) would agree at all.

    REST assumes a data-centric view of applications and assumes that PUT (create), POST (update), and DELETE (delete) can be used to cover all of the transformations a data resource might undergo. GET is, of course, used to retrieve data resources.

    Adam is probably correct in saying that most sites purporting to be RESTful use only GET, and that they make excessive use of HTTP query parameters. Personally, I would call them RESTful query applications, not full REST applications.

    Perhaps I’m oversimplifying, but the only query parameters in my REST applications are used to identify whether the response should be the default XML, or XHTML for display formatting. The URL, itself, identifies the data resource — and the HTTP verb identifies what is to be done with/to that resource. PUT and POST carry their data in XML format in the post data stream. My Web user interfaces are AJAX (built with the GWT) so there is no difficulty working with XML.

  8. REST == HTTP GET ??? Can’t be further from the truth. To the contrary REST encourages proper use of HTTP verbs. For example Rails REST implementation uses GET, POST, PUT and DELETE.

  9. Vitaly —

    You must not have read the comments, where I clarify my post to say:

    “This is not what *I* define as REST, HTTP+POX, and SOAP, or believe the “correct” definitions are.

    However, in my opinion, based on talking up eBay web services at many places for the past 2.5 years, if you went to a couple of web conferences and polled the attendees on their definitions of the terms, the results would be what I describe above.”

    Things have changed a lot around REST in the past 4 years, so I don’t think I would make those statements today, but I still contend that was common opinion in 2006.