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.

Very interesting. I’ve been reading good things about WinFS, and generally about other facets of Longhorn, since the PDC.

And now micros~1 is releasing the Word and Excel XML schemas… with perhaps-not-unreasonable licenses.

I don’t have a lot of stock with the “official” WS-* specs or technology stack they’re creating, so that analogy is lost on me. ;) His analogy is empty: all those awesome Amazon WS efforts are based on REST, not SOAP + WS-*…

Providing the infrastructure to get applications storing structured, relational data sets is a GoodThing. I have a bad feeling there will be an extra level of useless complexity to it, though.

I don’t think that it’s going to be useful. Programs are only as useful as they provide services — not data — to other programs. All those cool tools that he mentioned should be HTTP servers, and speak to eachother [and to the OS] via well-defined and common [RESTful ;)] interfaces.

The GNOME people almost got it right — but chose fsck’ing CORBA as their IPC mech. tsk-tsk-tsk. Especially because at the time it was clear HTTP was winning. Ah, well — I didn’t see it either.

Perhaps a storage mechanism can assist in that, but if it’s only at the data-transfer level, interesting functionality [mostly queries, I've been thinking, but also application semantics and manipulation constraints] will need to be re-implemented all over the place. And that’s the hard part.

Objects vs. Resources

There is a fundamental difference between objects and resources, and it’s really important. Objects are data + behavior, whereas resources are just data [and links to other data, if you're smart]. It’s the associated behavior that makes things scale badly. There is a world apart from objects: the semantics of the data itself are of primary importance, not the semantics of an interface to that data.

Tools

There are plenty of tools for RESTful systems … you’re just taking them for granted…

• Apache / Tomcat / Resin / JBoss
• Web-browsers
• httpclient / nogoop / URLConnection
• Log analyzers
• Sophisticated Proxies and Caches

All these tools solve very tangible problems, and have been shaken out over a long time. The tools for some other technologies seem to exist primarily to solve problems or reduce work created by the technology itself… though in some cases they do solve a higher-order problem, and are useful. WSDL is a good example: a reasonable resource/interface-description language, and, hey, it can be applied to RESTful interfaces very well.

Tools aren’t overlooked because of religion — they’re overlooked because they defocus developers from solving the real problem-at-hand rather than the details around the technology brought to bear in hopes of solving the problem at hand.

CRUD operations masked over a database

How is GET http://www.google.com/search?q=important+search+term a “simple CRUD operation thinly masked over a database”?

Or a POST that buys you a ticket on an airplane and moves you across the country?

It’s not that the operations or verbs or especially their implementation is simple. It’s that there’s a simple interface to them. REST requires a constrained interface, not a constrained implementation. In fact, it enables the implemention to grow unconstrained by a tightly-coupled interface. It’s another form of encapsulation — but of the procedural implementation, not the data. In fact, a view of the data is given primary importance.

Business tasks

You’re correct in saying that business people don’t care about the implementation details … but only until you tell them “no, we’d have to spend 6 months re-architecting the system for that.” Our job as engineers is not only to implement the currently-required functionality, but also to keep the system healthy and able to grow. They also don’t care what language we write it in [although they do from time to time], but we choose what language to write it in for a variety of time/skill-set and growth concerns. And with respect to this thread, I know which technology is available in nearly every language we would every even consider working with, and it isn’t SOAP, RMI or XML-RPC…

There are some things that require foresight, and can’t be designed for the moment; that’s why it’s called architecture, and not design. APIs are one of them, and networked APIs even more so, especially with the expectation that the system will grow very quickly.