Application Programming Interfaces

Lesson 5: Application
Programming Interfaces
What is API?
API or the Application Programming Interface serves as
a mediator that enables software or Web Pages to
communicate with each other. It carries both the request
and response from both pieces of software. An API
works as a middleman, taking the request from one
piece of software, and then replying with the appropriate
response from the other.
As Developer
A developer, you can create apps for yourself or for
your clients as well. You also have the option to make
the apps available for the public to gather customers.
As a Customer
As a customer, you can take advantage of the apps
made available through API publicly or contact
developers to make your own apps
API design and Maturity Models
A. Richardson Maturity Model
Levels of Richardson Maturity Model:

1. RMM0- The RPC, SOAP, and GraphQL APIs belongs to
RMM at level zero
2. RMM1- This level somehow possessed a notion or concept
that represents the notion or action that API adopts.
3. RMM2- This level follows the HTTP protocol and consumes
most of the benefits of the Web infrastructure.
4. RMM3- This level has met the constraints of the REST API,
provide links, distinguishes responses, and respects HTTP
Protocol
B. Amundsen Maturity model
Levels of Amundsen Maturity Model
1. AMM0- In this level, the persistent layer, for example the
database, and the client has no abstraction at all.
2. AMM1- In these levels clients were presented with the
implementation objects instead of dealing with data stored
in the database.
3. AMM2- Has a higher level of abstraction and decoupling
from internal models, successfully managing to decouple
the actual implementation internals and persistence data
model from the resource representation.
4. AMM3- Focuses on APIs as products that consumers can
take. Its affordances were modeled according to the user's
stories on API products.
Trends in the adoption of modern APIs
A. End-to-end experience
-APIs that were built on supporting and responding to customers,
employees, and partners.
 API Design
-Axel Grosse, VP of Innovation, delivered the API First initiative across
Axway.
 Security
-Through API organizations can: decentralize; monitor API against
breaches and security vulnerabilities.
 AI and ML-based APIs
-Evolution of natural language processing especially within the context of
Business Intelligence Trends combining big data, embedded, visual,
spatial/location, text, web, network, and mobile information.
The Kitchen, The Waiter, and the Food
Top 11 Misconceptions of API’s
Myth #1: Our API works!
The fact is, most API development teams build and ship
without proper testing or monitoring practices to ensure
that the API being delivered does exactly what it’s
supposed to do, reliably and safely
Myth #2: Nobody uses SOAP
This could be one of the most prevalent API
misconceptions that exist today, but it grossly
misrepresents the current API economy.
Myth #3: Top-down creation of APIs is only for elaborate
architectures
APIs come in all shapes and sizes, especially in the enterprise.
Myth #4: You need to adhere to REST principles
One of the most constraining business practices is to follow
strict adherence to some form of guidelines even when they do
not make sense for a given situation.
Myth #5: Metadata is bad
Put simply, the idea that Metadata is bad is patently false.
Metadata is just ‘other information’ than the primary data of
purpose.
Myth #6: SSL + OAuth is enough
Thorough security is never locked to one layer, so it’s
important to have multiple layers of security considerations in
place in order to deter hacking attempts and reduce single-
point vulnerabilities.
Myth #7: Their API cannot be hacked
Each of the points above applies when you think about
integrating with 3rd party APIs as well. If they do not have a
zero-day response policy, you may want to reconsider trusting
your data with their web service.
Myth #8: Our API cannot be hacked
Just because you haven’t been hacked yet, or you have taken
what you believe are adequate measures to protect misuse of
your API, rest assured your API will be the target of hacking
attempts from malicious users and bad actors.
Myth #9: Their API will always be available
Do you think that 3rd party API you just integrated with will
be around forever? API companies, especially those who only
produce APIs, can very quickly crumble unless they have a
healthy ecosystem and leadership to back them.
Myth #10: APIs are secondary to a business
Even if APIs are perceived as just “glue” for your
organization, or if instead of shipping a public API you use
them internally, integrations between systems are a vital part
of the health and function of a business.
Myth #11: APIs only solve a technical problem
APIs do not have buttons and flashy graphics, but that doesn’t
diminish their importance to non-developers.

Application Programming Interfaces

Uploaded by

Copyright:

Available Formats

Application Programming Interfaces

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Programming Interfaces

Uploaded by

Copyright:

Available Formats

Lesson 5: Application

Levels of Richardson Maturity Model:

You might also like