REST API vs. SOAP Web Services Management

more and more, projects are utilizing api management in those architectures now and pushing on web services' door.

the web services legacy

web services is a vast array of reasonably well-defined xml-based, transport agnostic, definitions that allow data communication between parties. the protocols and definitions cover everything from the message content to the meta-data and systems surrounding the content e.g. security or notifications of changes.

that definition misses as much as it says.

xml is a hard thing for human beings to read. the ws standards can be bloated. the tooling around the standards can be poor, given the complexity of the standards. the definitions themselves are sometimes loose, and thus interoperability (one of the main reasons originally cited for using web services) is not as good as it could be.

that aside, web services have been tremendously successful in what they are good at — interoperability of large enterprise systems. these enterprises liked the idea that web services made them vendor neutral (in theory). they also liked that having standards means cheaper developers — when something is standard, it can be learned by more people. in addition, there was an implementation arms race amongst the application server vendors, who just loved selling their latest and greatest server. this was an all-around win-win.

we can see that rest is gaining more and more popularity, while web services are loosing popularity each day.

the case for restful api management

i believe that there are three things making the case for restful api management and challenging web services' domination — and they are not all technical.

changing demands

the world is getting faster and faster. consumers are demanding more and more real-time information, sometimes from places where it was never being exposed before. direct interaction with data, and just the data, in a simple way, is being demanded by the new world order.

as this data demand has increased, companies are exposing their data-sets in order to encourage the use of it by third parties. often this exposing of data is done only to enable the third parties and may not have a direct impact on their own bottom-line. this has been coined the " api economy ."

decreasing time-to-market and complexity hiding

• time-to-market: over the past few years, digital disruption has increased. each company wants to start selling its products as fast as possible. therefore, when building apis, reducing time-to-market is much more important.
• sales growth for select internet retailers: time-to-market is more valuable than ever before as companies strive to keep up with their fresh competitors. it's not just the old pre-internet companies that are struggling to keep up. there is data to show that even the early internet giants are also being overtaken by new start-ups who are leveraging the social media age to their advantage.
• complexity hiding: if you're a computer science grad, it would have been drummed into you on day one that you hide away complexity as much as possible when you are writing code. yet, we didn't do that when it came to system configuration and administration. this is mainly because software, and technology in general, has moved on so fast that user interfaces and tooling was secondary to getting the function out of the door.

with the advent of the mobile age, users are expecting those same rich user interfaces in everything they do.

making apis easier to implement, secure, and manage reduces skills requirements and speeds time-to-market.

changing clients

the third reason web services are not today's technology of choice is because mobile devices and clients with rich user interfaces are the modern way. this is complementary to hiding the complexity on the server-side. these applications are being written by developers who want to focus on the user interfaces and don't want to learn the other deeply-technical data handling skills. how they access the data is almost secondary and their skills are not in that area. they just want access to data, as and when they need it and in a simple manner.

micro services and agile development

the business needs highlighted above are having further ramifications in the project delivery.

microservices' popularity are rising.

with the promises that they hold 'just when you need it' access to data and services, microservices are challenging the traditional soa architectures' hold on the enterprise. they fit well into the api management ease-of-use paradigm.

micro-services are still in their ascendancy , and tooling and architectures are still being invented. even so, they are already challenging web services with their promises to deliver just the right amount of access to the systems. this also fits nicely into the agile methodologies being employed by most businesses today. small sprints and piecemeal construction techniques require "just enough" work to be done to get from a to b.

we can see the ramifications of agile and api tooling today — around 75% of api management projects are internally focused. this tells us that apis are not just about directly making money by selling data, but that they are being seen as today's best-practice.

i'm convinced that we will see fewer and fewer web services used internally and externally, but they aren't dead just yet. i expect standards to play a bigger part in api management but its emphasis on simplicity and complexity hiding will stop standards being api's death knell.

i also believe that same simplicity push will have ramifications for lots of other software products when customers realize that enterprise software doesn't always have to be so hard. please check the restful apis predictions post for further reading.

i've shown how web services grew out of a world that was demanding standards. this enabled web services and its associated architectures to dominate the market by enabling a generic software workforce and cross-vendor interoperability.

api management is being born into an ever-speeding, real-time world. rich user interfaces are being written by developers with the interface in mind more than the data. this is driving simpler tools, integration architectures, and techniques.

this, as they say, is the perfect storm. where once a web service would be created with all of its complexity, there will now be apis with all their simplicity and developer-led tooling, speeding time-to-market.

i strongly believe that the tools that simplify the creation, testing, and configuration of rest apis are at the forefront of a trend to the simplification of other products — but that's for another day!