Do you need APIs?

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?
More Questions
  • 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?
..and some more!
  • 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.

Microservices, SOA and APIs

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.

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

Webinar On-Demand

Exploring Microservices, SOA and APIs - Friends (or) Foes?

For more information regarding our API Management and Edge Integration please reach out to