Computers don't care whether your resources are directly addressable

The article Roots of the REST/SOAP Debate (along with many others like it) claims that SOAP web services have a limitation in that resources they work with are not directly addressable via a URI, but that you have to connect to the SOAP endpoint and then call a method on it. The analogy used is as follows:

Let me offer an analogy. Suppose you were living temporarily in a hotel. The hotel might not have direct dial connections from the outside. In order to call a room you have to contact the operator first (this is like contacting the "SOAP endpoint") and then ask them to connect you to your room.

This is simply incorrect. Saying that you need to contact the operator first and then connect them to the room implies that to make a call to a SOAP service you have to first connect to the service endpoint itself, and then send a message to it which performs an operation. When you're writing code that uses web service proxies then it may appear this way because you first create the proxy and then call a method on it, but this doesn't reflect what actually happens on the wire.

When you create the proxy nothing at all is sent on the wire, it simply constructs a local object that knows where to send requests to (you do not need an instance of a proxy as it could also be done with static methods where you pass the service URI in each time; the proxy instance is typically used for convenience if you're making multiple method calls). When you call the method on the proxy, then a single message is sent to the service URI which interprets it using the designated method, and sends a response. From an HTTP perspective, this is exactly the same mode of operation as REST-style services.

The analogy continues:

Now imagine that there is an outside service that you would like to buy. It is a once-a-day automated wake-up call and horoscope service. You try to sign up for the service but when you are asked to enter the phone number to call back you realize that there is no single number you can provide. The service must contact the operator first and then the operator must patch them through to you. Obviously the computer on the other end is not going to be smart enough to know to go through the operator and the operator will not know to patch the call through to your room.

So lets say that the person in the analogy does provide them with a direct phone number, and the service is ready to call them back with a horoscope. Assuming both parties speak English then the service might say "Hello, your horoscope is..." or it might say "Good morning, today you will be..." and the person would understand either because we intelligently interpret the response. However computers do not do this because they are not sentient; they need a well defined response representation and will not understand the horoscope unless they already know what it is. The article does allude to this fact later...

If two HTTP services can agree on an information representation (for instance RSS (the Rich Site Summary) or SAML (Security Assertions Markup Language) then those two services can communicate about these information resources merely by passing URIs to resources.

...but it forgets to include the point that if two HTTP services have agreed on the information representation of the response, then they could also easily agree on the representation of the request. This means that as long as the service knows how to call the phone number you pass then it doesn't matter whether it needs a payload, which means it doesn't matter whether it is a directly-addressable REST-style URI or a SOAP web service URI. The problem is not the protocol itself; the problem is a lack of universal data type definitions.

I know what you're thinking at this point - that it's simpler just to use a REST-style URI than a SOAP web service for the callback as you don't need a payload. And you're right. But lets explore the last quote a little further and talk about retrieving RSS feeds. If I told you that the RSS feed for this blog was at http://gregbeech.com/blogs/tech/rss.aspx then you'd find it easy to get the latest posts, but if I told you that this URI is capable of restricting posts to date ranges then what URI would you use to only retrieve posts in the first half of 2007? And would you extend the URI in the same way on an RSS feed that wasn't generated by Community Server?

Exactly.

As soon as you want to do anything other than call a static URI on a REST-style service, you need to know how to construct and extend the URI to return the right data. And if it's a complex service you may also need to pass an XML payload containing the data (this is particularly common for PUT commands). Just because a service uses REST-style URIs does not mean that it can be easily used by any other service, irrespective of whether it understands the response format.

So if REST-style services are no different in their on-wire interaction to SOAP services, and are no more interoperable than SOAP services, where does the argument come from that they are preferable because of their directly-addressable URIs? Well, people care what the URIs are so they can type them and see where they link to before they click them, and they don't want to have to create a payload because it's inconvenient. A service client, however, does not care what the actual URIs are as long as it has been told how to build them (which means it does not care whether resource is directly-addressed using a REST-style URI or whether it is indirectly addressed using a SOAP service) and similarly has no issue with creating a payload as it has no concept of convenience.

All of which means that any preference for REST-style services over SOAP services on the basis of them being directly addressable or "more like the web" is based on a flawed anthropomorphism of a service client. So lets drop this pointless facet of the SOAP vs REST argument once and for all, OK?