Always curious and looking for good solutions i started to think about this.
I saw one of the following options:
- Just expose the (web)services through a web gateway and use http basic authentication over SSL for security
- Make REST adapters and expose those
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.
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.
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
You must also think about non-functional requirements, like
- 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
A lot of products can be found here: http://pages.3scale.net/rs/3scale/images/KL-api-managment-providers-guide.html
- Azure API Management
- SOA Software
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.