Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Where integration and policies come into play with API tool selection

Integration, policy enforcement and service exposure are key areas to examine when considering an API tool.

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.


The pace of change in many industries is making delivery time a key factor in API strategies.

A system may have integration points, but if the system needs to be accessible outside of the firewall, that integration point probably shouldn't be exposed as is. The data may need to be filtered or formats may need to be converted from extensible markup language (XML) to Javascript object notation (JSON). In other situations, there may not be a system involved and instead the data is sitting in a repository ready to be exposed. Someone from outside the organization certainly shouldn't have the ability to send arbitrary structured query language commands to the database.

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.

Policy enforcement

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.

Service exposure

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.

Follow us on Twitter at @SearchSOA and like us on Facebook.

Next Steps

Effective ways to connect to JSON APIs in an Android-based project

This was last published in May 2014

Dig Deeper on API management strategy

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Are you in the process of selecting an API tool?
Market reach
Todd, thanks for an thoughtful perspective on integration. I'm wondering if the major API management platforms you've seen offer robust support in this area, especially in transformation, filtering and aggregation? These adaptation capabilities are often needed for internal interop as well as external. I don't have intimate knowledge of the vendor products, but I had the impression that robust adaptation, going beyond simple REST/SOAP and XML/JSON conversion, was not high on the list of features for most API management platforms. What do you think?