WSO2 API Manager Community Features: The Social Side of Things

Ability to build, nurture and sustain a healthy community of subscribers (API consumers) is one of the most prominent features expected from an API management solution. However the ability of the solution to support a rich and growing user base never stands on its own. In fact it's always contingent upon many functional, usability and social aspects of the underlying software. Techees such as myself, usually do a good job when identifying and implementing the functional side of things, but we suck at identifying other non-technical nitty-grittys. Therefore when designing the social aspects of WSO2 API Manager, we went through a ton of API management related literature. We wanted to make sure that the solution we build fits the customer needs and industry expectations well. We read many articles, blogs and case studies that highlighted the community aspects expected in API management solutions and how various software vendors have adopted those principles. We also talked to a number of customers who were either looking to enter the business of API management or were already struggling with some API management solution. As a result of this exercise we were able to identify a long list of functional and non-functional requirements that has a direct impact on the social aspects of API management solutions. I'm listing some of the most important ones here:

1. Ability to associate documentation and samples with APIs
2. Overall user friendliness of the API store
3. Ability to tag APIs and powerful search capabilities
4. Ability to rate APIs
5. Ability to provider feedback on APIs
6. Ability to track API usage by individual subscribers

If you go through the WSO2 API Manager Beta release you will notice how we have incorporated some of the above requirements into the product design.  If you login to API Publisher as a user who has the “Create” permission, then you are given a set of options to create documents for each API.

Again we have taken into consideration the fact that some API providers might already have tons of documentation, managed by an external CMS. For such users, it is not required to import all the available documents from the CMS into the WSO2 API Manager. They can continue to use the CMS for managing files and simply manage file references (URLs) through the API Manager.

Once the APIs are published to the API Store, subscribers and potential subscribers can browse through the available documents.

Subscribers are also given options to rate and comment on APIs.

API providers can associate one or more tags with each API.

Subscribers can use these tags to quickly jump into the APIs they are interested in.

In the monitoring front, WSO2 API Manager allows API providers to track how often individual subscribers have invoked the APIs.

In general, all the above features combine to give a pretty sleek and smooth API management experience as well as a strong notion of a user community. Feel free to browse through the other related features offered by WSO2 API Manager and see how the end-to-end story fits together. Personally I don't think we are 100% there yet in terms of the social aspects of the product, but I think we are off to a great start (anybody who tells you that their solution is 100% complete in social aspects is full of crap).

One very crucial feature that we are currently lacking in this area is alerting and notifications. Ideally the API Manager should notify the API subscribers about any changes that may occur in an API (for an example, an API becoming deprecated). On the other hand it should alert API providers when an API is not generating enough hype or subscriptions. We are already brainstorming about ways to add these missing pieces into the picture. Idea is to take them up as soon as the API Manager 1.0.0 goes GA so hopefully we can have an even more compelling community features story by the 1.1 release.