Yesterday evening I attended an
ACS Web Services SIG talk called
"Implementing an Asynchronous Web Service." I thought a little light
education wouldn't go amiss and the title seemed innocuous enough, so
I duly turned up at the ACS offices in central Sydney and sat at the back
where all the naughty kids sit.
That's when they ambushed me. OK I should have been suspicious that Hao
He was one of the presenters, but two slides in and KER-POW, "... and we
will using the REST architectural style..." Oh man, I'm getting that sinking
feeling - for all I know the whole audience could be RESTafarians. I'm
looking round nervously, thankfully I'd made a good choice to sit at the
back and not too far from the nearest exit :-)
In actuality the talk was pretty interesting. In terms of
addressing the asynchronous behaviours, the speakers (Bill
Donoghoe co-presented with Hao) were pretty honest (with a little
prodding from some "pommie" bloke in the audience) that full asynchronous
behaviour isn't really an option for most developers today. They discussed a
simple polling pattern and agreed that sometimes it just makes sense to do
synchronous communication rather than polling. Although the implication that
synchronous consumers block while they're waiting for responses from
services is being economical with the facts (hint: threads).
The really interesting stuff came about when they were challenged about
the REST aspects of the application. Again the standard REST attack of
uniform interface good/rpc bad came out, amongst others. This is a flawed
argument in my opinion for a number reasons:
- Malicious payloads can be propagated irrespective of your transfer
semantics, and insecure code can be executed whether your service is
RESTful or not. The "safe" nature of the Web doesn't get round buggy
back-end implementations.
- We're past the RPC stage of Web Services, and we've been past it for
a while now. Message to the REST community - stop telling us that we're
playing catch up and see what's really been happening on our side of the
fence.
- The uniform API isn't uniform. For each HTTP verb (GET, POST, PUT,
DELETE) the accompanying message can be arbitrary. That is, you can't
POST a purchase order message to a REST service that expects to receive
a circuit diagram. At some point you have to understand the messages.
- The HTTP verbs are too numerous. Sure only GET and POST are usually
used, but these are too numerous and too protocol specific too. You
really only need a processThis(SOAPMessage) method on every service if
you're in a true asynchronous Web Services environment. Granted if you
want synchronous communication, that might need to return a SOAPMessage
too.
Sure some people are still building Web Services like CORBA with angle
brackets, and I've discussed these issues before: it ties into the
WSDL isn't an IDL argument. However, in the
asynchronous case, imagine your Web Service is just like a letterbox.
Letters happily fit into the letterbox and get processed by the back-end
(i.e. you), but the 42" plasma screen TV you ordered doesn't fit into the
letterbox - it doesn't match the physical dimensions (as per its "schema").
This seems RESTful, no?
The fact is that regular Web Services have a far more uniform interface
than the REST style. I've laid down the challenge before, but you can't get
much more uniform than one (imaginary) verb, can you?