I am going to start this blog with a caveat: This blog is not intended for integration professionals nor programmers (nor to weigh in on any architectural war). I wrote this for the average business person that wants to understand what all the fuss around REST is about.

All business processes require data of some type. A majority of the time that data lives in some other process, person, app, solution, system, or service. Around 2012/13 I started hearing a lot about REST and REST services and how they were the wave of the future. Previously, it was SOAP this and SOAP that. At the time, I kind of knew what REST was and what it was for, but only in a very vague way. I still didn’t understand why I needed REST.

One of my processoholic resolutions for 2016 was to bring process to the people by explaining process and its supporting technologies in a consumable and meaningful fashion. With this resolution in mind, it was time to dust off that computer science degree I earned so many years ago, and figure out why REST is important (and truth be told, not knowing was driving me crazy.)

REST stands for "Representational State Transfer." This blog was obviously all for naught. The definition is so incredibly intuitive I don’t have to explain any further, right? Or it could still be 100% not clear to the non-techies of the world. When it comes down to it, REST is just a style of exchanging information between applications.

First off, every time you see the word “style” you could just as easily substitute “way of thinking,” “school of thought,” or “approach.” REST is a specific school of thought around how to exchange information between applications.

You may have also seen the term RESTful. Since REST is a way of thinking, a web service or API can’t be REST... they are RESTful services or APIs.

REST is a style because it doesn’t dictate how things have to be done—it would be a standard if it did that—it is just a set of rules or constraints. If you follow them, then you are RESTful. If you don’t, you are not.

There are some guidelines and best practices around what the “right/best/easiest way” to create a RESTful app is (E.g., use HTTP). When it comes down to it, dev teams could go full MacGyver on it and implement REST with duct tape, bailing wire, and some chewing gum if they are talented enough and don’t mind throwing away the wisdom of all those that came before them. I personally see this as a pitfall of REST, but then again I haven’t met many developers that go out of their way to reinvent the wheel when they have a deadline (maybe just for fun on occasion). This is probably safer than it first appears.

The developers like to talk about REST constraints (rules) and maturity models (stages) a lot, but I am not going to go into that. There are plenty of resources all over the web which already covers that. As an architectural style it has many technical benefits, and I did my best to translate those into corresponding business benefits.

REST may not dictate how you implement it, but a vast majority of the time it is implemented with HTTP. Which is the same technology you are already using to browse to this very blog entry. What does this do for your business?

• Out-of-the-box HTTP has standardized and easy to use capabilities to create, read, update, and delete data. When apps are talking with each other, a majority of the time they only need to create, read, update, or delete data. When you do have additional needs, move to one of the other styles or standards (E.g., SOA) that allow you to build that extra little something special. When you don’t, use what is already there and get to your end goal faster!
• This uses all the same ports and protocols that your normal goofing off on the internet… I mean work-related web research does. No jumping through hoops with the security people (kind of… Be safe and don’t take APIs from strangers!).

REST eliminates a lot of overhead; it is usually referred to as being lightweight. When they say lightweight, they are talking photoshopped supermodel skinny compared to the old standards. What does this do for your business?

• The smaller it is, the less money it takes to operate.
• The smaller it is, the faster it loads. Since humans have recently developed shorter attention spans than goldfish, this is becoming a crucial aspect.

With REST there is no contract. Contracts in this sense define exactly what each side (the request and the reply) could/should contain. What does this do for your business?

• Much like in real life, a contract between applications is binding. Changing a contract is painful and affects everyone who has agreed to it. Changing the contract for customer B means you are also changing it for customers A, D, 4, zA, Q and all the others you don’t know about. No contracts mean you can adapt your processes to your business or service rapidly and without major disruption.
• With REST the service is always right (within reason). All error handling, variations, and exception handling become the client’s (requestor’s) responsibility. Great thing if you are the service, a bit more work if you are the client. Small price for the business agility that is delivered to both sides.

REST eliminates the need for sessions. Sessions are a semi-permanent interactive information exchange between two computers or applications. Translation: Sessions are temporary but sustained connections between two things for data exchange. Sessions are evil. What does this do for your business?

• Sessions must be created and maintained on the server. Thus sessions limit how you can scale. Sessions don’t transfer across lots (or an elastic number) of systems very well. Sessions are very difficult to work with in larger environments or the cloud. Get rid of sessions, and you just got rid of half of your scalability problems. Bring on those Black Friday shoppers!
• Sessions must be created and maintained on the client as well. This means they are really horrible for mobile devices, cloud services, or any offline activity. Get rid of the sessions, and you are much more ready to go mobile or to the cloud!

I have the feeling that I am just scratching the surface on this subject. If there are some technical benefits that I didn’t translate that you would like to see, feel free to leave them in the comments. I am sure this blog will get a few amendments as I decode the technical stuff a bit more.

If I were to boil it down to a single sentence for my conclusion on why REST is important: REST makes your business processes easier to talk with, faster to load, easier to change, easier to scale, and available on more formats (E.g., on-premise, cloud, mobile). Why didn’t they just say so in the first place?!?