Getting Your REST is Important
Blog: The Tibco Blog
I am going to start this blog with a caveat: This particular blog entry is not intended for the integration professional nor for programmers (nor to weigh in on any architectural war), it is meant for the average business person that wants to understand what all the fuss around REST is.
Back in November of 2015, ActiveMatrix BPM 4.0 introduced the capability to consume RESTful services directly from processes to complement its inbound REST API. Your processes can now consume and produce REST services. At that time, I kind of knew what REST was and what it was for, but only in a vague way. I didn’t know why I needed REST.
One of my process-oholic resolutions for 2016 was to bring process to the people. My intent was to explain process and its supporting technology in a consumable and meaningful fashion. For this resolution, I introduced how to explain BPM in 5 words: process, people, context, actions, and outcomes. With this resolution in mind, it was time to dust off that computer science degree I earned so many years ago, and figure REST out (and truth be told, not knowing why REST was important was driving me crazy.)
Starting with the basics, what does REST mean?
REST stands for representational state transfer. This blog was obviously all for not. 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 transferring information between applications.
So, what makes REST a style and what does that mean?
First off, every time you see “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 transfer 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), but developers 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 any developers that are down for reinventing the wheel when they have a deadline (maybe just for fun). 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 that cover that. As an architectural style, it has many technical benefits and I did my best to translate those into corresponding business benefits.
Now we are getting to the meat of things, why is getting your REST so important to your business (processes)?
REST may not dictate how you implement it, but a vast majority of the time it is implemented with HTTP. Which is exactly the same technology you are 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 supports you to build that 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 (be safe and don’t take any APIs from strangers!).
REST eliminates a lot of overhead, it is usually referred to as being lightweight. We are talking photoshopped supermodel skinny. 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 a very important aspect.
With REST there is no contract. Contracts in this sense define exactly what each side (the request and the reply) could or 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 contract means you can adapt to your business or service rapidly 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. It is a small price for the business agility that is delivered to both sides.
REST eliminates the need for sessions. Sessions are evil. Sessions are a semi-permanent, or temporary, interactive information exchanges between two computers or applications.
- Sessions must be created and maintained on the server, thus sessions limit how you can scale. Sessions don’t transfer across many or an elastic number of systems very well. Sessions are very difficult to work with in larger environments or in 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 or any offline activity. Get rid of the sessions and you are ready to go mobile!
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. But if I were to boil it down to a single sentence for my conclusion, REST is easier, faster, lighter weight, more agile, and is built for mobile and cloud. Why didn’t they just say so?!?
You can read more about ActiveMatrix BPM and its REST capabilities, which spawned this entire blog, here.
Leave a Comment
You must be logged in to post a comment.
