2014/09/13

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:

Just expose the (web)services through a web gateway and use http basic authentication over SSL for security

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 ConfiguratorAs a service provider you publish the APIs (services) and the documentation.

API ConfiguratorWithin the API Configurator you can define the exposed services and the integration with your backends.

Traffic ConfiguratorHere you can define and monitor the security policies of your APIs.

Developer PortalHere 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 ManagerAll 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.

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.