Not every service needs to be exposed as an API, and not every API needs to have a public managed proxy. So when do you need APIs, and what is the difference between SOA?

Questions to be asked

What API authoring capabilities will you need?
Where do I want my API Runtime to exist? Cloud (or) On-Premise?
How much security and run-time capabilities will you need?
What data formats do your payloads need to support?
Who will be you API consumers and what sort of experience do they require?
What existing business services do you have that you want to expose?

How easy is it to push APIs from Test to Dev to Prod?
How much control do you have over the environment and deployment architecture?
Does the product have built-in capabilities for invoicing, monetization and payment processing?
How strong and flexible are the product's API Policy Creation and Enforcement capabilities?
How secure is the API Gateway and Runtime?
What is the level of logging and analysis available?

What heterogeneous integrations are possible such as LDAP, Service Repositories and Gateway integrations?
What sort of product maintenance and roadmaps are available from the vendor?
How large is the development and support community around the product?
How deep is the training, knowledge pool and talent pool around the vendor’s product offering?
What level of insight and analytics are given for APIs?

Private (or) Public APIs?

Requirements	Private API	Public API
Creation Criteria	Based on the Custom business logic, and intigration requirements during application development process	Turned and designed per the needs of the external partners and third party developers
Purpose of API Consumption	Increase internal app development productivity,integrate applications within and across line of Business (LOB) resulting in streaming business operations	Increase partner business opportunities, and create new business models,and in some cases, direct consumer integration
API Discovery	Can be published on the same developer platform used by other internal applications willing to consume the APIs	Should be published on a developer portal which as proper access rights to external developers and partners
API Subscription	Stringent subscription plan might not be required	Diverse subscription plans are required for API consumer to subscribe to and then consume based on SLAs,Payment Plans etc.
API Policing	Metered,rate limited, coarse grained security control API is based on Enterprise line of business needs and access rigths	Need Grained Api control around the security,access, rate limits,SLAs,and access limits based on partner usage models and subscription PLANs
API Access	May or May not needed special tokens or keys to access the Aapi's.Depend on the sensitive nature of data being exposed	Need API keys abd security tokens to access the API'S
API invocations	Usually high number of transactions /sec	Dependent on buissiness requirements for access to external stakeholders and can implement throttling mechanisams as needed

Microservices, SOA and APIs

The future is microservices! Microservices are an architectural style to develop applications as a collection of small services that are running their own process, focusing on a narrow goal and communicating with lightweight protocols such as HTTP. When APIs, Microservices and SOA all come together, the future will be truly here.

Comparing SOA and APIs

So back to the fundamental questions, why do we need APIs when we have SOA? While APIs are similar to SOA, they are the next good thing to happen for application integration.

SOA	Microservices
An architectural ion computer software design in which application components provides services to other components via communication protocal,typically over a network	A software architectural style in which complex applications are composed of small,independent process communicating using a language-agnostics API'S
A service in SOA may have many responsibilities	A services microservices should be fine-grained and should only have a single responsibility
SOA is using heavy-weight technologies and protocols(like Sop etc)	Microservices are the leaner,meaner,and more agile approach(REST and AMQP)
SOA is more platform based and done more on premise	Microservices came into light with the evolution of Saas and PaaS approach,more respected with Hybrid/Cloud Integration
SOA is always an enterprise architectural level	Micro service is an application centric architecture,often reffered to asdecentralized services/API model
In SOA the product or platform is defined at the enterprise Level	Microservices,you has the freedom to choose your own technology like(Node.js,Java+MongoDB,etc)

API Management

Our API M Offerings

Do you need APIs?

Why Miracle

Do you need APIs?

Questions to be asked

Private (or) Public APIs?

Microservices, SOA and APIs

Comparing SOA and APIs

Thought Leadership

Team Miracle

Opportunities

Corporate HQ