Back in the day Web Services were the de facto standard for accessing "systems of record". SOAP web services popularity grew because of an option to share data, access from any system and security options. This type of architecture grew out to be synonymous with enterprise architecture.

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 are seen, by many, as bloated. The tooling around the standards is seen, by some, to 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-round win-win.

We can see that REST is gaining more and more popularity, while web services are losing 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 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 & Complexity Hiding

• Time-to-Market : Over the past few years digital disruption has increased. Each company wants to start selling her products as fast as they can, 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 & Agile Development

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

Micro Services popularity is rising.

With the promises that they hold of small 'just when you need it' access to data and services; Micro-services 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 less and less Web Services used internally and externally but Web-Services isn't dead just yet. I expect standards to play a bigger part in API-Management but API Management's emphasis on simplicity and complexity hiding will stop standards being APIs death knell.

I also believe that same simplicity push having 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.

Summary

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 work-force 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 tools like RestCase that simplifies the creation, testing and configuration of REST APIs are at the forefront of a trend to simplification of other products - but that's for anoth er day!