What is a Service Api
API stands for application programming interface, but that really doesn’t explain the power of three letters. Service APIs are snippets of code that allow an authorised application to perform actions both internally and externally to an organisation, and it’s the secret sauce behind Amazon’s success.
SERVICE API in action
Let’s have a look at an analogous representation of a service API in action.
In a world without a service oriented architecture, if you need to buy a widget you’ve a couple of options. 1. Telephone around potential suppliers, 2. surf the web, login to your supplier portals to see who has stock, at what price and lead time. once a supplier has been selected. The order gets entered in the accounting system, a purchase order is generated , and the item is ordered either via the suppliers portal or maybe an email is sent to order the widget.
The Elegance of a Service Orientated architecture is in its simplicity. It’s possible to use any application providing they expose Service APIs and communicate with any other application anywhere in the world
Service API’s can easily be stitched together to form far more complicated workflows. For example. a client orders a part from amazon which is going to be fulfilled by us. Amazon’s website calls our Quote API, and subsequently calls our Order API. Already your organisation has generated the opportunity to use dynamic pricing;if there are large numbers of orders for a particular part you can increase the price in realtime. You can also call delivery companies quote API and get the most cost effective delivery for that particular item. Now with two APIs we can accept quotes and orders not just from Amazon, but any platform with no additional overhead or cost apart from generating an authorisation key so we only accept quotes and orders from bonafide partners.
In another scenario a complex part or product is ordered. Service API’s can order all the constituent parts from differing suppliers, and the build can be scheduled depending on the lead times. It’s possible to deploy which ever work scheduling system fits our needs best. There is no need to use a globulous ERP system which limits the flexibility and innovation within organisations.
Service APIs – Amazon’s secret sauce
Amazon’s secret sauce is that every application in the organisation advertises service APIs, so every application can communicate with and make use of the functionality of every other application within the organisation. Not only that but authorised external clients, partners and suppliers can do the same. So in the amazon marketplace its possible for me to sell an item on etsy, and make a call to the Amazon Fulfillment API and have Amazon deliver that item from my stock held in their warehouse.
API Specifications
So do all suppliers need to have the same API? No is the simple answer. Each supplier publishes a API specification for their APIs, which details how we call their API and the format of the response. So now it starts to sound complicated. Each response from a supplier may be in a different format and might be using a different technology. That’s true but there’s a piece of middleware in between our application and our API; it’s called the Enterprise Service Bus (ESB), The purpose of the ESB is to perform translation between technologies, formats, and sequencing so our API doesn’t need to be concerned with that complexity. It’s done in one place.
Are API calls in realtime?
When a call is made to a remote API or even a local one, there may be other calls made by other applications, so unless some prioritisation feature exists calls will be processed on a first come first served basis. The calling API or the enterprise service bus will have a timeout configured, and if there’s no response before the timeout then a timeout error is returned. Therefore, there is no guarantee that the calls will be returned in the order that they were sent. Typically, though the response is received in a couple of seconds for external calls and milliseconds internally.
Why are Service APIs a business imperative
if your organisation implements just two apis – a quote and an order API. you can immediately implement dynamic pricing,
Business is facing a seismic shift; the previous tectonic movement in computing was the advent of ERP (SAP et al) combined with the growth of the internet as the dominant marketplace. The next tectonic shift is the growth and ubiquity of AI. In order both to counter and take advantage of AI businesses need to embrace AI as not just a business tool, but also a threat and opportunity. Businesses will need to accept change as the norm, and that means being flexible, and able to quickly adapt to constantly moving goalposts. ERP has in the past been the goto computing platform but its all encompassing approach has led to a decline in adaptability. Sure the big ERP companies will be moving to a headless architecture and serive oriented architecture, but they will also want to protect their user base, revenue and that means in essence keeping their eco-system tightly controlled.
Recent Comments