Have you ever been thinking about API design guidelines for your APIs? Are all your APIs behaving the same way or are your API consumers struggling to find out how your APIs work?
I’m not telling you something new if I say the demands on IT from business are ever increasing. Certainly the last few years, business is looking more and more towards IT as a big part of the solution to their business problems.
The API Billionaires Club is about to welcome Trillionaire members. But how should you deal with it?
The amount of API traffic increases every day. But it’s no longer just the known players such as Google, Amazon, Twitter, Facebook and Salesforce (the API Billionaires Club) that will produce the related massive amount of data. Cisco estimates that by 2020 37 billion smart ‘things’ will be capable to connect with an API. The Internet of Things is here! But how should API-providers handle all these clients?
So you need to connect an application to an external system. Developers and IT architects know how to cover the technical side, with for example SOAP web services, REST APIs, or stored procedures. But there is more to integration than just a choice in technology. You also face a functional challenge: the relevant functionalities of multiple applications must seamlessly fit into each other.
In most application landscapes services tend to pop up like mushrooms, with little to no attention being devoted to decent service design or decent service-oriented architecture (SOA). Frankly put, this means you’re doing it wrong.