Note: This blog post was originally published as a white paper in May 2015 and has been updated for accuracy and comprehensiveness.
The API Economy is here. Enterprises are making business applications available through APIs to drive business growth and expose new opportunities. The business landscape is being reshaped as dramatically as it was during the rush to create an internet presence with a website in the late '90s. APIs are becoming the primary way that businesses interact with their customers, reach new markets, and provide the global app development community with the tools to deliver innovative new business capabilities to customers.
An API is really a product, and has to be thought of with the same rigor as any product. It is important that you identify the right business capability to expose as an API, the API is well designed and built, runs correctly, is well supported, and is promoted effectively. This blog walks through the steps you need to go through in order to help ensure your API succeeds.
Whether you’re just starting down the path with APIs, or you already have a great API in production, you need a solution that deals with all the things you don’t want to have to deal with. You should be focused on the business value and functionality of your API, rather than worrying about make sure your API is running right. In other words, if it has nothing to do with your core business functionality, leave the heavy lifting to an enterprise API platform.
APIs don’t typically exist in a nice little self-contained packages installed in your enterprise DMZ. In most cases APIs will be externally facing interfaces to one or more internal applications, often using existing service interfaces to create the API.
The big challenge is to take an existing service interface that is likely implemented using SOAP with WS-Security, or Plain-Old-XML (POX) over JMS or MQ, and turn it into a RESTful API with XML and/or JSON content. It is especially important with mobile applications to deliver the least amount of data possible to get the job done, with the least amount of back and forth dialog.
With the right enterprise API platform, you can quickly and easily create properly defined and structured RESTful APIs supporting XML and JSON that are built on top of existing internal services. Your API management solution should declaratively mediate between content types, transport protocols, security models, message exchange patterns, standards, and more. This will allow you to get your API up and running quickly.
Even though you may think of your API as an entirely new product, it is still going to rely on existing applications, and in an enterprise context, it had better be well integrated with your enterprise security and management systems, and with existing enterprise services and applications.
A good enterprise API platform will come with out-of-the box mechanisms for integrating with your enterprise identity and access management systems so that your developers can login to the community using enterprise controlled credentials, and APIs and apps can work with existing managed user accounts, providing single sign-on between apps and the enterprise applications they are using. This will help ensure that your app developers and end users remain subject to existing security and privacy policies and requirements.
The enterprise API platform will also be able to integrate with enterprise management and monitoring products so they enterprise network operations center can manage performance and availability, and will be able to leverage your existing investments in enterprise database infrastructure and datacenter operations solutions.
It’s tempting to think of an API deployment as a skunkworks project designed to get something off the ground really fast. Yes, you want to be fast to the market with your API, but you’d better make sure that you get it right.
Your enterprise API platform should help you make sure that you optimize your investments with strategic planning to make sure that you build the right API at the right time, to meet current and planned needs, understanding the dependencies between the API and existing business processes and applications. It should help you make sure you’re building your API correctly, with clean API definitions, good documentation, and just the right amount of architecture and program management support.
Once you’ve built the API, your enterprise API platform should provide the runtime infrastructure to make sure it’s behaving the way you want it to and is meeting QoS and security requirements. Finally, the enterprise API platform should help you with the process of publishing, socializing, and supporting your API.
So you’ve just built the best API in the history of APIs, and you’re going to have tons of businesses using it, or tens or even hundreds of thousands of apps with millions of users, and the new business will keep pouring in generating vast profits and turning you into the next billionaire, or at least netting you a pay rise, or some good kudos inside your company. The only problem is that you really don’t know how to tell people about it, and when you do find someone who’s interested, you have to be able to feed them all the information they need to use it without getting overwhelmed trying to support them all.
This is where you need an API portal within a social enterprise API platform, regardless of whether you are trying to broadcast your Open API to the whole wide world or to expose it to groups of developers inside your own business.
You want to market your API or app inside or outside your enterprise with a powerful search driven catalog offering rich social features like ratings, reviews and ‘following’. You need to publish your API into a catalog with appropriate descriptions and tags to make it easy for potential consumers to find it through search and browse, including external (public or enterprise) search engine integration and optimization.
Of course, once someone has found your API, they need to decide if it is the right API for them to use. This is where the definition and documentation capabilities come into play, and where the discussion forums and user following capabilities allow them to ask questions, or see how active the community around your API is.
Related >> What Is an API Portal?
People need to be able to use your API without burdening you with a ton of questions and complaints. You need to ensure that you define it properly, document it well, and publish the definition and documentation effectively.
A good enterprise API platform will provide a robust set of tools for API definition, documentation, and content management, as well as policy and lifecycle management. This allows you to make sure your APIs are correctly structured and well documented. The solution should also integrate well with internal design and development processes to help make sure that the internal services and applications that support your API are up to the task.
You’ve defined your API properly and have published it with well-structured documentation. It’s in the catalog with a nice description, an appropriate name and set of icons, and you’ve even convinced a few friends to post nice encouraging reviews and ratings for it. Now it’s time to hope that potential users can find it.
Your enterprise API platform should provide a powerful built-in system that creates an internal search index from all the content about the APIs and apps that it is aware of, complete with sufficient permission information so that it knows which users it can show search results for particular APIs and apps to.
Hopefully the phrase “all the content” caught your eye, because that’s one of the more interesting things here. The content about your API or app doesn’t just include its name and any description information you typed in, it also includes all the documentation, and most importantly all the discussion topics and comments posted about it. This means that if someone asks a question on your API’s Board about how it handles a particular type of widget, then when someone searches for anything to do with that widget, they will find your API.
Think about the use case where you are writing a piece of code and you run into a problem and use Google to search for the specific error code or exception text. Because a good enterprise API platform will index all this information, these types of searches work in real-time.
Another important consideration for the enterprise API platform’s search system is its ability to publish and maintain its index in enterprise or public search engines. This will allow your developers to find information about your API regardless of how they look for it, or which tools they are using.
You’re making real progress with your API now. It’s well defined and documented, you’ve published it into a dynamic catalog where users are able to find it, rate it, review it and discuss it. What more could you possibly want?
How about allowing apps to actually use your API, and controlling the way they use it? API management allows developers to define their apps – in much the same way that you defined your API. In fact, the app definition has all the same features with documentation, ratings, reviews, discussion boards and the whole nine yards, as your API definition. It also allows the developer to create a team of peers that can work together on the app. This may all seem a bit fluffy and useless, until we get to the real purpose of the app definition.
Your enterprise API platform should provision API access individually to each app. It should create an identifier for the app, allowing the app developer to upload a CSR (certificate signing request) for a locally generated public key. The app should then use this app-ID (optionally signed) to authenticate itself to the API management solution. The app developer should use the enterprise API platform’s developer community to find the API(s) they want their app to use, and initiate a simple approval workflow to grant their app access to the APIs.
Depending on how the API is configured, they could also request different throughput levels based on pre-defined quota policies. Once the workflow process completes and their app’s access to the API(s) is approved, the app will be able to begin sending requests to the API.
And that’s not all. You need the ability for an API to expose sandbox (test) and production endpoints, with a multi-step approval process for granting apps access to each of the endpoints. This may sound complex, but in most circumstances, sandbox access will be automatically approved, and getting approval for production access is a simple process involving a single button click for the app developer, and a simple response to a newsfeed item and/or notification from the API administrator.
One of the interesting side-effects of this provisioning process is that your enterprise API platform should be able to monitor the API from the perspective of each of the apps. The API administrator should be able to see all of the monitoring data and choose to see a chart showing which apps are consuming their API the most, they should be able to filter the monitoring data by app to provide support for a particular app owner, or use this data to identify poorly written or malicious apps that are causing problems for their API, so they could choose to disable or throttle them appropriately. Similarly, the app owner would see the API from the perspective of their app only. They would only see their traffic and performance information, and the usage data and messages their app generates.
It’s all very well to publish a great API, but there are a couple of things you have to be wary of:
A good enterprise API platform will provide a rich array of security capabilities for all types of APIs, including the ability to mediate between security models, standards and technologies to ensure seamless interoperability between externally facing APIs and the internal services that support them. These security capabilities should include:
All these capabilities and the huge range of supported standards and configuration options could make for a very complicated product, but a well-designed enterprise API platform keeps things as simple as possible, providing canned configurations for common scenarios with a comprehensive set of wizards for more advanced use cases.
Read More >> API Security Best Practices
An enterprise API platform should provide a powerful quota policy system allowing API administrators to provision capacity to apps as needed. This means that an administrator who knows how much traffic the API can handle could apportion this capacity over the apps that are consuming the API appropriately. For example if an API can handle no more than 200 transactions per second (tps) the administrator may choose to allow an important customer facing application to consume 100tps, and could then allow 5 less important apps to consume only 10tps each, and the remaining 50 apps would be only allocated 1tps.
The enterprise API platform should allow app developers to negotiate the quota allocated to their app during the access provisioning process, and facilitate a dialog between the app developer and the API administrator if the app needs more or less capacity at any point in the future. It should enforce the quota policies at runtime, denying or queuing up any requests that exceed an app’s allotment.
Assuming you’re following along with the various steps above, then by this point you now have a rock solid API that is well structured and documented, published in a catalog with great search facilities, and is protected from all kinds of bad things. Developers are starting to find it through the traditional search and browse models, but that’s not good enough in today’s social-media driven world. You need your API (or app) to go viral. Bring on the social world.
An enterprise API platform will provide the social platform for API management and app development. It will bring together API providers and app developers in an online social community. Whether this community exists inside your enterprise, as a private external community, or part of a broad public developer community is entirely up to you. The enterprise API platform’s social features should include:
Any user, developer, business administrator, or API provider should be able to invite other users to the party. Invitations should be able to be general, simply inviting a user to check out the community, or they could invite a user to follow an API, app, or Group, or join the development team for an app. In this way you can immediately create your own communities of interest around your APIs and apps. By encouraging the people you invite to invite their contacts too, you can build a huge social community connected to your resources.
Every API, app, user, business or group inside your enterprise API platform should have its own social forum – think Facebook Wall. This is a place where users will go to post comments or ideas, ask questions, or even raise support tickets. Depending on a user’s role they should get different views of the forums. The administrator of an API, for example, should see access requests and unanswered trouble tickets that would be invisible to regular users. The administrators would use the forum as a central place to manage the workflow of access requests and trouble tickets, and to make sure that any questions and comments are being answered.
This is a key concept - it’s not necessarily up to the administrators to answer questions and even tickets themselves - as the community around a resource matures, it will likely become more and more self-sufficient, with many questions and comments being answered by other users.
A standard old forum is a bit passé these days, so your enterprise API platform needs to be far more social. It should implement a Twitter-like following concept allowing users to choose to follow APIs, apps, Businesses, Groups, or even other users. Each user should have their own dashboard – like a Facebook news feed – that would aggregate all the discussion items and comments from all the resources the user is following. This would give the user a single centralized place to keep track of what’s going on with everything they are interested in.
One of the bigger challenges you’ll face with your API is the potential of becoming a victim of your own success. What’s going to happen when you drive this massive social adoption of your API? How on Earth are you going to manage the volume of support requests and questions you’re sure to get?
Again, your enterprise API platform will have the answers. The first thing, of course, is to make sure that your API is well-structured and well-documented, as we discussed earlier. You can make developers’ lives even easier by providing them with SDKs and code samples, and then publish and promote these with your API. But where the real beauty kicks in is when your developer community becomes self-sufficient and users start helping each other out by answering questions and even responding to trouble tickets.
Because everything should be so efficiently indexed, it should be really easy for users to search for errors, issues or questions, and get immediate help and answers from questions and issues that have already been resolved. Sure, you’ll have to put some effort into getting your community moving, but the time and energy you dedicate early on will pay enormous dividends later. As my mother used to say, “A stitch in time saves nine.”
Of course not every API will be destined to be truly “Open” - designed to target a broad community of app developers sharing ideas and applications in an open forum. In fact, we expect to see far more private or semi-private APIs that a business uses to share specific functions or data with one (private) or more (semi-private) partners.
A good enterprise API platform will enable this by introducing the concepts of API and app privacy settings, enabling a number of key scenarios.
In one of the most common scenarios you may have an API that you wish to use to enable integration with several partners, but you don’t want any of the partners to know anything about each other, or even to know that there are other partners using the API. An enterprise API platform will allow you to define a private API and invite users to follow and connect to it – the invitations are required, because the API will not be published in the search indexes and will not be visible to any user who has not been specifically invited. In this mode, user posts, discussions and comments would be visible only to that user and to the API administrators.
Read More >> What Is API Integration?
Another common requirement for private APIs is the need to create an API that is visible and consumable by a defined (invited) group of users. Any member of the group will be able to see posts and comments from other members, but the API and all its content will be hidden from anyone outside that group. This is particularly useful as a tool for publishing a version of an API for use by a beta test group, in advance of launching the API to the public.
All these capabilities sound great, but at the end of the day, the success of your API initiative depends very much on your ability to get your API in the hands of as many developers as possible. So how can you go about building your own developer community? Maybe a better question would be, why should you go about building your own developer community when there are already a bunch of communities out there? More to the point, what about your partners or other like-minded companies with their own APIs that a developer building an app that uses your API might also use?
Your enterprise API platform should support the concept of API provider federation to bring together communities giving developers access (with approval) to any API from any provider using a single app ID, and allowing providers to leverage the network effect of all the connected communities to find the broadest possible reach for their API. All this could be done with federated trust and permission models that would allow API providers to opt in or out at granular levels, and to choose the partners with whom they want to federate.
Read More in Our White Paper >> Federated Architecture For Enterprise API Management
An enterprise API platform that is offered as-a-Service as well as via on-premise or hybrid models would provide a ready-made community for its customers to connect to, whether they choose to become a user of the Platform-as-a-Service or install the product in their own datacenters. Customers should be able to choose how much or little sharing they do with the broader community, depending largely on how ‘Open’ they view their APIs.
Akana built its Enterprise API Platform product family to accelerate the API economy by helping developers collaborate around and manage APIs in a complex environment. It provides a secure, robust platform that companies can use to share their APIs with the developer community of their choice. The API Platform manages, monitors, and secures APIs, ensuring that they deliver the level of service customers and partners require; the security or corporate and customer information and assets; and the integrity of the corporate brand.
The Akana API management platform brings API providers and app developers together in a community that should be familiar to anyone who spends time on popular social networks.
It provides a connecting point where you can publish, promote and manage your APIs in a secure, scalable environment. You can manage your own developer community, or just plug into communities that already exist. Creative developers can find and harness your APIs, blending them with complementary APIs from your partners. These developers can then work together, share ideas and support each other in new and productive ways.
The Akana platform provides lots of social goodness, but we haven’t lost sight of the fact that the most important thing is to make sure you meet the needs of the day-to-day management of your APIs, and the applications that use them.
Our API platform stands on the shoulders of a rich heritage – Akana has been around the block a few times. We work with many of the Fortune 1000, meeting the needs of demanding production environments for their API Management.
The API Management Platform enables the full API lifecycle from planning and development through operations and community management to help you make sure you build the right API, build it right, run it right, and share it with the your developer communities.
Akana meets enterprise requirements, including security, integration with existing infrastructure, performance and reliability, and much more. It offers integration with enterprise identity and security infrastructure, enabling API security models including OpenId and OAuth. This ensures that app developers and end users remain subject to existing security and privacy policies and requirements.
Akana provides sophisticated yet simple security capabilities that allow API providers to control and monitor app’s usage of their APIs.
The Akana platform defines all security and quality-of-service through centrally managed policies, ensuring consistency between multiple API implementations and versions.
Akana allows you to define and manage your APIs using a wide range of messaging types and formats including REST/XML, REST/JSON and SOAP. You can create an API with multiple interfaces using different standards and different security mechanisms with no extra effort.
In addition to exposing new capabilities, you can leverage Akana to harness existing investments in web services and enterprise architecture, with new formats and policies specific to an outside developer group.
See how easy it is to create, document, test, publish, and market your APIs in the Akana API platform with a free 30-day trial.