This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

SOAP? REST? Whichever you choose, WCF is the right framework

Stefan Tilkov,

Dino Chiesa:

Sidenote: speaking of multiple interfaces for the same resource, check out what Amazon did with SQS:  there is a REST interface, a SOAP interface (described in WSDL) and a QUERY interface.   The REST interface is bona-fide REST.  It uses HTTP verbs like (GET DELETE PUT POST), and the URI corresponds or maps to the resource in question, for example the queue you’d like to operate on.   In WCF, to build this sort of interface, you would use a [WebInvoke] attribute on your service interface.  The QUERY interface on the Amazon SQS resource is, like the REST interface, always based on HJTTP, but QUERY is different than REST in that QUERY is always an HTTP GET, and specifies the object and verb in the URI.


The QUERY request to create a queue:

GET /?Action=CreateQueue&QueueName=Foo HTTP/1.1
The REST request to create a queue:

POST /?QueueName=Foo HTTP/1.1

Some people confuse or conflate REST with HTTP QUERY, but Amazon certainly does not. It doesn’t help matters that there is no widely accepted or adopted name for the HTTP QUERY services interface. Amazon calls it HTTP QUERY or justr QUERY but as far as I am aware, that name is not widely used by other systems who expose similarly architected interfaces.

How about “Abomination”? ;-)

On November 14, 2007 4:13 PM, Aristotle Pagaltzis said:

I like The Book’s name for these: “REST/RPC hybrid.”

On November 19, 2007 3:28 PM, Ganesh Prasad said:


The use of an overloaded GET to cover all verbs should be called HTTP Command. It’s the Command pattern over HTTP.

Actually, I think if they restrict the use of this pattern to just the three idempotent verbs (GET, PUT and DELETE) and use the POST-Redirect-GET pattern with POSTS, it wouldn’t be a bad substitute for a purely RESTful system. It would just lack formality.


On November 21, 2007 11:11 AM, Stefan Tilkov said:

Ganesh, it would not only lack formality, it would still be quite disastrous if GET’s safety guarantee was violated.

On December 12, 2007 7:01 AM, Ganesh Prasad said:

(Sorry, I seem to have forgotten my userid/password, hence posting anonymously).

Stefan, I too am against overloading GET with any kind of update semantics, but we were talking about applications that are already designed that way (using overloaded GETs or the QUERY interface). That’s the “they” I was referring to in my post. I certainly didn’t mean to propose this scheme as an alternative to REST for new applications. It would definitely be disastrous.


On December 12, 2007 7:53 AM, Stefan Tilkov Author Profile Page said:

Fair enough; I did not (and still do not) really understand your previous comment, then, obviously.