As a software developer, I’m starting to notice the winds of change blow through the halls of enterprise development. Of course, it doesn’t surprise me. There’s an old adage in software development that the only constant is CHANGE.
Modern day software development is all about CONNECTFULNESS. That is, one application communicating with another application. You may have heard about something called “IoT”, the Internet of Things. Soon, (actually it’s happening as we speak) everyday appliances like your fridge, your tv, even your vehicle, will communicate with other devices and services.
The mechanism by which this will happen is through either SOAP or RESTful services.
What seems to be happening in the Information Technology landscape is the rise of RESTful services over more traditional SOAP services.
To understand the change, it’s helpful to get a little bit of historical context.
Back during the dawn of the personal computer revolution, if you were a software developer, you created software that lived on a digital island. That is, your software would get installed by some end user, and end up living on their computer.
All the data and resources the application would need to operate, would be self contained within that same application. Remember that we’re talking at least a decade before the rise of the global internet. It was literally impossible for your software application to “fetch” data, files, or any other external resources outside of it’s own application.
But eventually, LANs (Local area network) technology allowed personal computers to communicate with each other.
Because of this networking technology, software (in the form of objects) was soon able to “communicate” with other software.
In the Java world, Java objects could communicate with each other through something known as Common Object Request Broker Architecture (CORBA).
In the Microsoft world, Microsoft software objects (COM) could communicate with each other through something known as DCOM, or Distributed COM.
This was great, but there was something you might have already noticed was lacking.
A Microsoft object could communicate with other Microsoft objects and Java objects could communicate with other Java objects, via their respective CORBA and DCOM technologies.
But what if a Java object wanted to communicate with a Microsoft object? You were out of luck.
In order for a Microsoft object to communicate with a Java object, you would need some sort of common data schema that different kinds of objects, built on completely different tech stacks, could use to communicate information with each other.
This gave rise to a great new data schema standard called XML. With XML you could now create a universal data format that is flexible enough to describe any sort of data object you wished to communicate between two different objects, even if those objects were built with different technology stacks, as we mentioned with Microsoft and Java technologies.
For instance, to describe a catalog of books, you could create an XML schema that would look something like this to describe a book and know what the author, title, and subject of a single book could be defined. Then wrap that up in a catalog that could contain a COLLECTION of books.
<?xml version="1.0"?>
<catalog>
<book>
<author>Robert A. Heinlein</author>
<title>Stranger in a Strange Land</title>
<subject>science fiction</subject>
</book>
<book>
<author>Stephen King</author>
<title>Carrie</title>
<subject>horror</subject>
</book>
</catalog>
With the rise of the internet, developers now had the ability for their software to communicate across a GLOBAL scale, across multiple continents, to other software objects, via XML and HTTP.
It goes by many names, but this overall technology can be referred to as “XML Web Services”, “SOAP (Simple Object Access Protocol) Services”, “Web Services”, or “WSDL (Web Service Description Language) Services”.
XML based web services is a powerful way of allowing communication between two endpoints that may or may not have been developed in completely different technology stacks.
The big heavyweights, Microsoft and Sun soon built lots of tooling and frameworks around the concept of XML web services, which solidified their legitimacy in the IT world.
XML web services were a boon to lots of business enterprises, which often are comprised of a mishmash of old and new technologies. Mainframes could suddenly “talk” with newer personal computers. Mobile devices, equipped with cellular network capabilities, could communicate the data stored on the mobile device to remote endpoints via this new XML web service technology.
And life was good. Suddenly software din’t live in its own digital island. With the power of web services, you could harness the power of the internet and reach out across the globe to any accessible endpoint on the other end.
But as with anything in technology, change is inevitable. And a new type of way for software objects to communicate with each other arose.
Something called REST based services. REST standing for REpresentational STate Transfer. A mouthful of big words, but in essence, it’s another way of getting one software object to communicate to another software object via an HTTP url value.
In a RESTful type service, you perform CRUD type operations. Create, Read, Update, Delete. Or in web server parlance, GET, POST, UPDATE or DELETE. You’re basically following the way a web server processes http requests.
For instance, most of the time, when you’re surfing the web around in a web browser, you are usually performing HTTP GET or READ type operations. When you’re filling out some online form in your browser, you are performing an HTTP POST (CREATE). The other two types of REST based operations are a little less know, but they are PUT and DELETE.
A typical READ/GET REST request would use a url endpoint to request some some sort of information over HTTP.
http://www.mywebsite.com/findEmployee/123
What this REST service is allowing you to do, is making a request to find some employee information for employee id #123.
You could literally use any modern web browser, plug in a url into your address bar, and you would see either your employee information return back in your browser window either as XML or something called JSON (Javascript Object Notation).
The main reason RESTful based web services have become so popular with developers, is its simplicity. REST based services can work with traditional XML, but the preferred data format is something called JSON, which is much less verbose than XML syntax. Which also means that a JSON object you send over a RESTful service can take up much less space than an equivalent XML blob of data.
Smaller data = faster journey between the source and destination endpoints.
With WSDL/XML type web services, the client who wishes to consume the XML web service, need to perform more “prep work” in order to make a proper XML web service call.
For instance, if I was a Java developer who wished to consume a WSDL/XML web service, I would have to run some tools against the WSDL (essentially an xml file which describes the location and functionality of the web service) to create some native Java objects which I would then have to import into my java project. These java objects (referred to as “proxy objects”) would then be responsible for actually calling the XML web service and transmit your XML data across the wire to the destination endpoint.
There is significantly much more prep work for the SOAP/WSDL service to get working versus the simpler RESTful service.
And as I’ve blogged about in the past, simple technology usually wins over complex or proprietary technology.
Of course, it doesn’t mean RESTful services invalidate the legitimacy of SOAP/XML/WSDL services. You choose the best tool in the toolbox for the job.
But I’m definitely becoming a fan of REST services due to its comparative simplicity over SOAP/WSDL services.
Simplicity and open technology seems to always win over more complex and obtuse technologies, every single time.
