The take up of SOAP was driven by its comparative simplicity to other prevailing distributed architectures (DCOM, CORBA, EJB, etc). The complexity only came in when people moved on from simple problems, and needed security, distributed transactions, reliable delivery, etc. The end result is a stack that is just as complex as the earlier alternatives.

When we look at REST we see the appealing simplicity. But that is only because it lacks the rich semantics to solve complex problems. REST is great in it's place, but don't try and tell me it can solve complex enterprise problems.

REST only deals with immutable objects that look like documents, because it's just HTTP. As soon as you want to do a partial update, it fails horribly. There's even been talk of adding a PATCH verb to HTTP, which only goes to highlight the point.

REST on business entities is like giving everyone direct read/write access to your database. That's fine, except everyone then has to implement the business rules underlying that update, or handle incredibly complex exception processing semantics.

Everyone wants simplicity. Just like everyone wants world peace and an end to poverty and disease. But the real world is inherently complex, and the solutions will be too. Sorry.

Could someone who has a clue what this is about explain it in monosyllabic words and no acronyms, pretty please.

It looks web related, so I should be interested, but sounds like a bundle of nested acronyms describing a lot of semantics that no-one with a job to do would give a shit about.

*blort*

You owe me a new keyboard and monitor! Where was the C&C warning on that one?!

See also WADL, or Web Application Description Language. Here's: http://tomayac.de/rest-describe/latest/RestDescribe.html a nice tool that can be used to create WADL and also generate client code (PHP, Ruby, Python, Java) from (a) WADL.