It would be nice to know that for $10 billion invested I’ll get a medicine that will do exactly… But it doesn’t work that way. In medical research, what is purchased is specific processes and people. The results are variable.

Building software has far more in common with this model than most of us are willing to admit.

It’s not time, it’s money. Here, I have this nice used car for you. It’s really cool. But I won’t tell you the price before you sign the contract. You don’t know how much will you pay. Would you buy it?

Estimation is not the right word. It’s quoting a price, that’s the right word.

It does not matter that it’s not possible to do it accurately, we must do something.

Besides, putting modification primitives behind POST is just hygenic – else a naive webcrawler can ruin your whole day. Once there was a wiki that had ‘delete page’ as a GET method… and it met a CEO’s PocketPC ‘cache this site so I can read it on the airplane’ software… resulting in a very unhappy sysadmin…

1) The consistency of SOAP is its only benefit – there is no agreed mechanism for service discovery in REST, and the lack of standard formats is a hindrance – not a solution to the well-known problems of SOAP. ATOMPub is emerging as an excellent standard for POX services, but JSON, while popular, has no means of defining or validating document schema and this makes *real* SOA harder to implement.

When implemented properly, SOAP has a lot going for it, but implementing it properly is difficult (read up on the WSS or WSE standards – zomgwtflololol).

2) REST, lacking a formalised message structure, would almost certainly save a few bytes on the wire if you wanted to pass a “3000 character sql statement”. SOAP would produce a larger message, particularly if you chose a light-weight format for your REST message. Incidentally 3000 characters isn’t a large message at one byte per character.

3) Don’t pass SQL statements to your web server. srsly dude.

4) Defining a service solely in terms of GET operations is *not* RESTful. It’s an HTTP service, but fails to capture the basic idea of REST – that we can represent an application’s state as HTTP operations over a set of uniquely identified resources.

I’m not a purist by any means, I’m a dirty, filthy hacker – but a GETful service is not RESTful, it’s just simple.

Furthermore, REST (sometimes) tends to scale because it differentiates between operations that change resources, and operations that do not. If all your GET requests are idempotent, then you can cache hard at the application boundary.

If your GET requests are really updates in disguise, then it needn’t scale any better than SOAP ‘cos you’re still doing RPC, except that you’ve dropped any sense of rigour in your request/response formats.

- Developers prefer writing code, than understanding the domain
- Business users/stakeholders want to see *results*
- Creating and delivering flexible prototypes takes too long

We have a product that attempts to tear down these obstacles, and:

- Allows developers to rapidly create prototypes using code
- Allows business users/domain experts to interact with the prototypes
- Allows all parties to understand and share the domain

The product is called “TrueView”, and I believe it tackles a very important part of the software design process.
You can learn more about it at http://www.evolving-software.co.uk.

Cheers,
Vijay