SOAP? REST? Whichever you choose, WCF is the right framework
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.
Example:
The QUERY request to create a queue:
GET /?Action=CreateQueue&QueueName=Foo HTTP/1.1
Host: queue.amazonaws.com
The REST request to create a queue:
POST /?QueueName=Foo HTTP/1.1
Host: queue.amazonaws.com
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”? ;-)
I like The Book’s name for these: “REST/RPC hybrid.”
Stefan,
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.
Ganesh
Ganesh, it would not only lack formality, it would still be quite disastrous if GET’s safety guarantee was violated.
(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.
Ganesh
Fair enough; I did not (and still do not) really understand your previous comment, then, obviously.