In the first article of this series, I introduced the five major capability areas an API tool should provide:
- API portal / consumer engagement
- Service lifecycle management
- Integration / service exposure
- Policy enforcement
- Instrumentation, analytics and reporting
The second article covered the first two of these. In this piece, I'll cover integration, service exposure and policy enforcement. In the last article in this series, instrumentation, analytics and reporting will be covered.
The API tool space has roots back to enterprise application integration technology, where the most important capability was creating pathways for two systems to talk to each other where previously they could not. Over time, the need for products to provide glue has lessened; however, new challenges exist.
There are still plenty of legacy systems in use today that lack modern integration capabilities. There is still a need for technology that can rapidly expose an API and enables access to information and systems in an enterprise.
The pace of change in many industries is making delivery time a key factor in API strategies. Enterprises definitely want to look for integration and service exposure features in an API tool. This may include adapters for talking with major commercial products, and should definitely encompass:
- Transformation capabilities
- Filtering and aggregation
- HTTP andJMS/MQ transport support
- Multiple message format support (SOAP, general XML and JSON, at a minimum)
In order to apply the integration logic required, the API management platform must provide a component that sits in the pathway of the runtime communication, acting as a gateway. Preferably, the product should allow for deploying as many gateways as needed to segregate traffic and avoid having unrelated interactions impact each other.
Once these gateways are in place, the platform is ready for the next capability area -- policy enforcement. In the heyday of SOA, policies were a very hot topic that drove standards discussions (WS-Policy, WS-MetadataExchange) and technologies (SOA governance suites). At a theoretical level, the idea of a contract containing policies that govern the interactions between two parties makes sense. In reality, there are really only three policies areas that see significant use: security, traffic management, and version-based transformation and routing.
Security policies, with the big three of authentication, authorization and encryption, are clearly well known. They're also probably three that already exist for internal service interactions. The sweet spot for API tools will be in handling this for external interactions. If the API management technology is performing identity management, it's a natural fit for it to also authenticate the tokens gateways receive and ensure they are able to access the functionality. It's also critical because the remaining policy domains are dependent on it. This is where the notion of a contract has stuck.
Traffic management policies enforce access limitations that may be imposed on consumers. As soon as internal systems are exposed to external ones, it is important to be able to protect systems from bad consumer behavior and enforce different levels of access. This means restricting requests to certain rates; prioritizing traffic from one consumer over another; or where there aren't restrictions, ensuring that there is an upper cap of request rates to properly protect systems.
Finally, there are version-based transformation and routing policies. These may not be needed, as simple load balancing may be sufficient in many cases. There may be a need, however, in version scenarios. If the version to be used is implied, rather than explicitly specified, the identity of the consumer needs to be looked at and routed to the appropriate version based on the policies for that consumer.
I consider this an edge case, as I believe that explicit versioning is far more common. When versioning APIs, there's something different about them that will either be backward-compatible (either explicitly, or through a transformation), in which case there aren't any issues, or will not be backward-compatible. Still, it is always good to have a discussion with vendors on their versioning support.
About the author:
Todd Biske is an enterprise architect with a Fortune 50 company in the St. Louis metro area. He has had architecture experience in many different verticals, including healthcare, financial services, publishing and manufacturing, over the course of his 20-year career.