Doorgaan naar hoofdcontent

API Management

I currently work for a customer that wants to expose its "services" to partners and other external consumers. They do not want to build websites themselves anymore, but instead have the services published and used by partners. So how can this be done?

Always curious and looking for good solutions i started to think about this.
I saw one of the following options:

  1. Just expose the (web)services through a web gateway and use http basic authentication over SSL for security
  2. Make REST adapters and expose those 

Requirements 

However soon i also discovered:
  • Consumers have to be managed. You have to manage the client credentials. For a few consumers this is doable, but for a couple of hundred or thousands this can be cumbersome
  • Consumers have to find the services somewhere. What is the functionality of those services? Is it soap or REST based?
  • Consumers want to test the services within a sandbox before actually using them
  • As a service provider you have to manage the life cycle of those services. You can not just make a service obsolete, because clients may still use that version
  • As a service provider you do not know how many times the service is used. You may want to throttle the usage, based on i.e. the clients or the services.
  • The services may also be used internally (SOA based services) and these services may be different. Internal maybe may use more data than external. How do you handle this?
  • As a service provider you want to expose services using different technical interfaces. For example through REST, soap or maybe even JMS. So you need (data) transformation functionality.

Functional components

The more i read about it, the more i came to the conclusion that API Management might be a good solution for this company. Such a platform (or product) comes with basically the following functional components:

  • Portal Configurator
    As a service provider you publish the APIs (services) and the documentation.
  • API Configurator
    Within the API Configurator you can define the exposed services and the integration with your backends.
  • Traffic Configurator
    Here you can define and monitor the security policies of your APIs.
  • Developer Portal
    Here the clients of your APIs can search for APIs and test them within a sandbox environment. Here the consumers can subscribe for APIs as well.
  • Traffic Manager
    All API calls run through a API gateway to canalize the traffic. Here the API keys are checked against the policies. May this user actually use this API.

Product selection

The next step in the process is to actually select a product. Because the API Management products are fairly new, this selection can not be based on my personal experience with one of the products. I did two things:
* Read a lot about API Management on the internet
* Talked to other people with more practical experience with products

So what to look for when selecting a product. This depends of course on the functionality you would like to have and the priority and weight of those requirements.
You can think of:
  • Which API Keys must be supported (i.e. OAuth, http basic authentication, certificates)
  • What are the backend systems you have to integrate with
  • Do you need manual and or automatic approval of API subscriptions
  • Do you want a sandbox environment for consumers
  • Which API interfaces do you want to be supported (i.e. REST/XML/JSON/Soap/JMS)
  • Which search features of the developer portal do you want
  • What governance supported? Multiple versions of the API
  • etc
You must also think about non-functional requirements, like
  • Costs
  • Is the community of the (freeware) product active or not
  • Do you have local support available
  • How is the documentation of the product
  • Do you want a local and or cloud version of the product
  • How mature is the product

Some products:
  • Layer7
  • Apigee
  • Mashery
  • WSO2
  • Azure API Management
  • IBM
  • SOA Software

Example: WSO2

Let me first say that i do favor WSO2 perse, but it is an open source product that is already very mature with its API Management product. It has more components that can be integrated as separate components. So whatever you want to use, you can plug in.

  

Reacties

Populaire posts van deze blog

OSB 10gR3 and SWA and MTOM

This blog is about using soap with attachments and the use of MTOM within the OSB (10gR3). A service is created that accepts a soap with attachment (DocumentService) and translates it to a service that accepts a binary element. MTOM is used for performance reasons for the second. Some notes: * For the use of attachments you need RPC-style document instead of the usual document-style. This due to the fact that the document-style limits a message to a single . * A service can not have both SWA and MTOM within OSB. First a WSDL is setup for the DocumentService: The $attachments variable holds the attachments and the body holds the attachment data. Also other data is stored within the attachment element (see h

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .

Book review: Data Management at Scale (Piethein Strengholt)

 This blog is a review of the book "Data Management at Scale (See also at bol.com ) Data Management is a hot topic nowadays and this book does a fantastic job at adding value to this topic. It is a must read and one of the few technical books I finished reading in a weekend. The book gives a fantastic overview on how to implement a Data Mesh data architecture. The Data Mesh concept is explained by Martin Fowler here . The book is a good mix between conceptual and implementation architecture level. It gives a lot of examples of how this architecture at scale can work, for both small and big companies. It is practical and I used it to implement it at one of my customers. The book describes an architecture in which the focus is on the DIAL (Data- and Integration Access Layer).  On a high level the book covers the following topics: The key principles for data management at scale - Domain-Driven Design  - Domain Data Stores - Meta data management Ready Data Store The concept of servin