This technology is cool, JSON, but if the structure is that simple it is easily parsed anyway. Though having a standard library to bundle and unbundle it is nice.

I have been working in webservices the last nine months or so. I am not that impressed. It is neat that I can talk back and forth by RPC across the internet, but CORBA was doing that on local networks in the past. The public network is after all one big local network.

So I can get behind REST being a back-to-basics style of development with URI, HTTP and HTML as the most efficient means of developing webapps.

Stupid acronym puns aside, the idea of REST is to take what we all take for granted in the Web (ie. HTTP and URIs) and use it with other payloads (other than HTML, images, etc.) and other HTTP Methods than the usual GET and POST. REST defines identifiable resources (URIs), and methods for accessing and manipulating the state of those resources (HTTP Methods).

I don't like complexity in software. I don't even like when people do fancy sh*t in code; the code itself should be mundane, boring and utterly consistent. It is rare for software developers to see an abstraction they did not like and want to implement. So it becomes abstraction, on abstraction, on abstraction.

That has its place, but it is hard to argue with a concrete object. Same with interfaces and abstract parents. They might be fine in a library that is being publicly distributed, where behaviour needs to be enforced, but in an internal app, the concrete object is the rib cracker. No ambiguity there.

Anyway.