This blog post is contributed by Katherine Sanders, an IBM Software Services for WebSphere (ISSW) consultant based in Hursley, United Kingdom.
Application programming interfaces (APIs) were a notable theme during the IBM Impact 2014 conference as an enabler for mobile integration and a component of the composable business. During the day 1 general session, Robert LeBlanc, senior vice president of software and cloud solutions, spoke about how systems of engagement and systems of record must be integrated, and how APIs can be used to “rapidly assemble your applications” using a building block approach. On day 3, Michael Curry, vice president of WebSphere Foundation product management, discussed how IBM API Management in combination with cloud integration and the Internet of Things allows you to “innovate more quickly and uncover new ways to transform your business.”
The next release of IBM API Management was also announced at the conference. IBM API Management 3.0 builds on version 2.0, which I described in a previous blog post, and adds improvements in the following core areas.
Integration with user registries
Version 3.0 supports integration with Lightweight Directory Access Protocol (LDAP) registries that authenticate user credentials for the Developer Portal or API Manager. It is also possible to use a different LDAP registry for each user interface, so you can have an external one for your app developers and an internal one for your API developers.
Role-based access control
Support has been added for multiple user roles. Each user role is associated with a set of permissions that enable access to different capabilities for viewing and working with the APIs.
SOAP web service support
It is now possible to manage SOAP web services alongside Representational State Transfer (REST) APIs. SOAP services can be published to the developer portal and invoked through the API gateway. SOAP service definitions can be loaded from Web Services Description Language (WSDL) files or discovered directly from IBM WebSphere Service Registry and Repository.
API plans provide a mechanism for grouping API resources and making them visible as a unit for use by developers. Targeted API visibility means that a plan can be published to all consumers or published to selected consumer organizations or communities (groups of consumer organizations). API resources become visible in the developer portal only to users who belong to organizations where one or more plans that contain the resources are published.
Each plan can have a different rate limit to control the number of calls each consumer can make per time interval. The rate limit can also be set at the resource level, for example to allow GET resources to be called more often than POST resources. Additionally, the assembly capability can be extended by contributing custom policy definitions such as data field redaction or user authentication that are run as steps in assembly flows.
A 50 percent simpler architecture
As I discussed in a previous blog post, IBM API Management 2.0 required four different components for management, analytics, assembly and the gateway. This has been halved in version 3.0: the assembly capabilities have been merged into the gateway server, and the analytics have been merged into the management server.
An IBM API Management installation is no longer constrained to a maximum of two management servers. A minimum of one management server is required, and additional servers can be added to increase capacity (particularly for analytics storage and processing) and resilience.
Flexible configuration of users and organizations
It is no longer necessary to create a tenant as the basis for a user account. Instead, users can be members or owners of organizations, which are the context in which APIs and applications are defined. A user can be a member of more than one organization.
Multiple environment support
API providers can define multiple deployment environments that act as logical partitions for the deployment of APIs and plans. A separate Developer Portal is associated with each environment but they are all managed from the same API Manager console. APIs have different endpoints in different environments. Environments can be configured to restrict deployment and publishing activity to privileged users. Multiple environments are typically used to separate development, test and production environments for API deployment. This feature replaces the need for separate installations or tenants for different deployments from version 2.0.
In situations where development and production environments are highly separated, disconnected deployment allows API and plan contents to be exported as deployable content from the source environment and imported into the target environment without both being accessible from the same API Manager console.
All the user interfaces feature an enhanced design that results in a more intuitive user experience: the Cloud Console for the operations team, the API Manager for the API developers and product managers (API providers), and the Developer Portal for application developers (API consumers). The workflows have been streamlined to reduce the number of steps required to perform common tasks, such as the initial setup. The navigation menus have been condensed into a new action bar down the left side of the screen that is always visible. It is also possible to categorize APIs, plans and organizations by adding tags to simplify management for larger numbers.
IBM API Management 3.0 offers many improvements over the existing offering, which was already a complete solution for rapidly creating, securing, controlling, testing, deploying, analyzing, versioning and managing REST APIs for internal or external consumption. API assembly and proxying capabilities allow creation of new APIs from existing business assets or cloud services through a configuration, not coding, approach. Application developers can be securely and dynamically onboarded through the self-service Developer Portal. Access to APIs can be managed by using a combination of API keys and secret keys, and application users can be authenticated using HTTP basic authentication or OAuth 2.0. The solution provides built-in caching, quota management and flood control, and can be configured to exploit existing IBM WebSphere DataPower appliances. Detailed business analytics and operational metrics also help you analyze API utilization.
If you’re interested in the IBM API Management product, you can learn more about it on our new API developer community, leave a comment below or connect with me on Twitter.