AsynchronousBlog

Wish I’d been at what sounds like a downright bloody battle down under. :) Responses to some of the points:

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:

1. 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.

This must be in response to something said at the event … ?

2. 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.

Fair enough.

3. 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.

There are two parts, here: 1. Application Programming Interface 2. Messages carried over API.

In RPC, both are arbritary, which has a known set of problems in a networked environment crossing trust boundries. REST seeks to limit one — the API — and let the complexity be managed in the messages. Moreover, REST encourages a well-known set of widely-agreed-to message types.

More importantly, however, by fixing the verbs — the API — you have a much better chance of being able to intermediate in those operations. Because the semantics of the API operations are fixed, you actually have a chance to get in the middle of the communication.

4. 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.

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?

Mark says it better, but here’s my response:

That’s a red herring. The fact is that if you only have a unconstrained ‘do stuff’ method, you’re in a far weaker position than HTTP’s 4(-6) well-defined verbs. At thet same time, if you have an arbritary set of undefined verbs, then you’re not very well off, either.

The real issue is the definition of meaning of the API operations. GET, POST — and even PUT and DELETE — have very specific defintions and requirements on their behavior. And beyond that, there are a set of headers which further affect how those verbs behave in well-specified, well-thought-out and well-tested ways. This is important because it enables a class of tools to operate over the traffic, as well as providing a necessary semantic base on which other specifications to be based.