so let's go in and understand more about the definition driven approach right so
API's have been around for like a long time it's not just ten years ago it's
actually APIs have been around before even the PC was created but if I
want to like take a more microscopic view of this if we want to
start from say the early 90s APIs have primarily been in the SOA-based
infrastructure or architecture right, in the service-oriented architecture APIs have
been around then in came Salesforce and in 2000 they kind of like popularize the
notion of web api's after which ecommerce companies specifically like
eBay and AWS as well as Amazon the e-commerce giant they've all like taken
really well to api's and finally of course we saw how social media really
took advantage of API so like spearhead the platform movement which essentially
allows developers to come in and actually third-party developers to come in
and start building additional services and applications on top of existing use
cases and existing services and with the big smartphone revolution that came
about as well APIs became incredibly useful
and popular to not just have great applications of course but also to give
you that speed and efficiency which you're so used to right now. In an iPhone
or like in a Samsung phone. Finally of course we're seeing how APIs not just
help in tech in just broader in any use cases but they're also
incredibly useful to actually act accelerate application development
primarily in micro services and what if you wanna like flip the way api's have
been developed we can actually take you know like the 90s early 2000s
approach of api's and just look at what the objectives were when you have been
you were kind of building APIs and that in that timeline at that time in that
period of time and over there it was more of a very data-driven approach
right they want if you were a developer at that time you were primarily building
out an API with specific data objective in mind you wanted to transfer data
between different services and that's why you built out the API and these APIs were
modeled canonically and all the nomenclature the data the nomenclature
the descriptions which you've used very cryptic in the sense that they they just
used the same nomenclature as you would in a data set. Very technical jargon a
very industry domain focused jargon which was not really it wasn't really
built for it I guess reusability or long-term scalability and finally of
course no documentation and would be lucky if you had good documentation for
api's again because APIs were never actually as a concept or as a technology
framework there there was never an implication of how you could actually
help in long-term sustainability of your applications or your services but now
we're seeing there's a big revolution that's happening and I'll be
talking about three important trends that validate why it's so important for
you to start for you to change your approach towards api development.
The first one is companies are now entering the platform ecosystem we saw
that in the social media age but now we're actually seeing large enterprises
B2B companies all opening up their products with third party APIs
to essentially transform their products into platforms and when I mean
when I say platforms it's essentially allowing developers maybe internal or
external developers to add on top of your existing services and extend upon
them right when we're seeing so many people actually take up the platform
economy and platforms have actually if you look at the entire timeline of how
much revenue was driven by the internet in general platforms actually count for
the majority of this they are the major drivers of revenue and economic growth
but when it comes to the Internet and this is the reason why all of these
organizations were even like small teams are trying to take advantage of the
platform economy that we're living in and platforms are primarily driven by
APIs. APIs are the foundation of the platform economy. And the second
trend we're seeing is there's this API first approach. Now in the API
what do I mean by an API first approach? Well to understand the API first
let's take the example of a monolith traditionally when you build
out your application you would start with understanding what the plan was and
from there you'd build out the database right and then after you build out the
database your different back-end teams will start building out the business
logic in finer granular modules which will eventually get consumed by the
front-end clients and the front-end teams will work on that. Now here the
problem is that one is you have to have so many dependencies between each level
to even get the application to its final state right and this is in an era where
we're increasingly saying companies becoming more agile and more quicker and
more and having better go to market strategies and consumers demanding more
from companies this approach becomes is not scalable and it's also doesn't it's
not really optimal for speed and efficiency to push features of the
market. So in the API first approach, you actually start out with an API
layer understanding once you once you have a clear idea of the plan you
actually start out with the API interface and actually mark out for each
of these interfaces what is the data that you would be showing or giving in
those in but by each of these in each of these api's and from there once you have
your APIs in place and because you have more data that gets transferred
between each of these APIs you have your front-end teams and your back-end
teams all working simultaneously with each other to essentially build out that
service right so there's no actual real dependency because once you have an API
or contract that actually defines what the arrangement is between the back end
and the front-end team so in the API first approach as well it's like api's are the
primary elements of your product and service strategy and this is actually a
real life use case right we see companies like Netflix Facebook Amazon
all adopting this all adopting APIs a primary change agent within the
organization to accelerate development and pushing features faster pushing new
updates faster to market in the big and finally the biggest trend is the
explosion of the API economy we're seeing that so many organizations are
not investing in an API strategy. There are over
100,000 publicly available APIs for consumption and 85% of enterprises are
estimated to enter the API economy to have to have invested in an API strategy
by 2018 that is just enough reason for all of us to start thinking about how
can we best leverage api's to accelerate our development so this is not just
public API so when we talk about the platform economy but it's also even
internal private APIs and the core of all of this is we're seeing these these
three different trends actually affecting the way we think about APIs
because the modern API is no longer data-driven it's actually consumer
driven even if you have if it makes so much sense if it's a public API but a
lot of people might be thinking well if I have a private API why do I have to
think about this well even if it's a private API you want to build APIs for
long term sustainability that means you'll have so many different internal
stakeholders all consuming this API and so they need to have an easy way to
understand what this API does they need to be thinking about how you can
discover this API. You need to be thinking about long term sustainability
of how this API touches on various parts of your system so it's not just it's not
it's not data driven and it's not built for short-term goals it's built for
long-term consumer driven tactical strategy that that the modern API tries
to satisfy. The modern API is also staged for self-service development
and consumption. So in an ideal world you should give an API to
someone, should hand over the API to someone, and they should be in enough
position to just look at the API and reach success with that API. The modern
API is also built to enable speed of updating and maintaining not just
your own internal applications but also allowing third party services to consume
it. And finally the modern API has a common vocabulary. You have so many
different programming languages in the world that are coming up JavaScript
there's always something new happening in that world where there's so many
different technology and technology stacks available your API is if you're
building it for long term sustainability should not impose limitations for
different people consuming it in terms of technology stack. So five builds in
service in PHP I should not be imposing restrictions saying hey the other person
should also be built consuming this in PHP for them to be successful it has to
have a common vocabulary of consumption so the modern web api is based on
reusable HTTP standards and it's built for consumer demand and for self-service
consumption