To get the conversation going here’s another question. What is Heterogeneous Interoperability? It’s a bullshit term. The English has been skewed. Let me spend the next 1hr of my time trying to figure it out.

“Heterogeneous” means diverse in character or content. That definition crap. That’s basically a NON definition.

“Interoperability” is the ability of making systems and organisations to work together

Wow. So all I’ve got is something that applies to everything. E.g. my brothers Heterogeneous Interoperability is crap.

If we consider a website that relies on a variety of sources for it’s functionality and information – we find that a complex network of resources can be combined together to offer a compelling solution. An example that might offer this is a news website. A news website might rely on news data from a variety of source, some login functionality and sharing features through various social networks, multiple devices and relevant advertising content.

As we all know, the news is mostly advertising, right?

REST comes in super handy when working with these sorts of distributed solutions. A distributed solution where the resources used by the application are distributed across many disparate networks.

The rise of devices is another contributing factor to the increasing importance of REST. Each device has a unique way of access data. Each device wants a different set of data. For example, a GPS enabled device will want data that is relevant to it’s location.

This “rise of the devices” also brings into play the need to offer data from various sources. There isn’t a single interface any more. One website used to be good enough. Now each version of the service is tweaked depending on the device. The pace at which these various applications are deployed and consumed also gives rise to the importance of REST. Applications evolve independently.

Network inconsistency and data use management is also an important focus of REST. Finding ‘fall off’ solutions and only using the services that you need are all fundamental considerations of this type of architecture.

The capabilities of modern solutions are often derived from the capabilities of other services. Being able to mash-up ideas is part of the REST ethos.

Cloud computing offers elasticity. REST is one way to fully utilise these benefits.

I’ll cut through the crap. REST is a style. REST is an architectural style.

By the way, what the hell is the primary advantage of migrating a solution to the cloud?
It’s to pay someone else to manage your service infrastructure needs. The scalable benefits are for large scale systems that are rarely achieved. The “cloud” is a place where lots of business have decided to pool their resources in a dynamic flexible scalable growing elastic network infrastructure ‘place’. Cloud computer is a meaningless buzz word. In reality – the computers in the ‘cloud’ are just the same as the ones in your ‘data centre at work’. Cloud computing helps you draw pictures and make your infrastructure look pretty, easy and often cheaper.

Here are some stupid (often not even real english) buzz words that might be relevant. Heterogeny, Scalability, Evolvability, Visibility, Reliability, Efficiency, Performance, Manageability.

RPC. Another acronym. Pfff.
RPC stands for Remote Procedure Calls. Boring.

REST. Eek. Another acronym i’ll forget by the time I finish the next sentence.
REST stands for Representation State Transfer. I have no idea what that is supposed to mean, even though I do have a handle of those three words.

I’ll cut through the crap. REST is a style. REST is an architectural style. It’s not a protocol. It’s not code. It’s a application design.

HTTP?
Weird thing. RESTful services don’t need to run on HTTP. They can run on any protocol. FTP. TCP. Whatever. Weird. Having said that – most RESTful services are built on HTTP.

When working towards REST. The following ideas can help us discuss out progress.
POX (plain old xml) > Resources > HTTP Verbs > Hypermedia. If all 4 of these elements are considered, your solution is RESTful.