Successful enterprise API implementations are built on a set of localized, project-level efforts with services that have clearly identified and accountable business and technology owners. Ownership defines an API domain. Deciding what services are core to a business owner and should be implemented within the owner’s API domain versus consumed from a third-party API domain becomes a critical part of building a Federated API.
Understanding core capabilities provided by API domains is a crucial task at the enterprise-level for encouraging efficiency through re-use and for keeping focus on core business services. No one wants to reinvent the wheel and as business functions become commoditized, enterprises are more likely to consume third-party APIs while focusing on developing only key differentiating services. A collaborating Federation of APIs is a core best practice in most corporations.
As API domains mature, they may be consumed by other API domains. “API Domain Jumping,” — rapidly integrating a plethora API domains in a Federated API environment becomes a reality for organizations. Here are the top three Federated API requirements that corporations must first address before embarking on a meaningful and sustained cloud computing deployment:
1. Federated Identity Management
Almost all API interactions require establishing trust between service consumers and producers via identity tokens. Such tokens come in a variety of formats, both protocol-based (OAuth, HTTP Basic Auth, SSL Mutual Auth, Cookies) and message-based (SAML, WS-UserName, WS-X.509, WS-SAML). In addition to these standards-based tokens, services may require consumers to understand proprietary tokens, for example, identity attributes stuffed in HTTP header or buried within an XML element. Generating and consuming identity tokens for authentication and authorization decisions becomes a critical aspect of API communication.
Implication on cloud computing: Corporations have to be prepared for consuming and generating a variety of proprietary and standards-based identity tokens if they are to utilize cloud computing. All cloud computing providers (SaaS, PaaS or IaaS) require identity tokens for interaction. For example, if an enterprise decides to use Amazon EC2, it will need to manage Access Key ID for REST-based interaction with EC2 or X.509 certificates for SOAP-based interaction. Other Cloud providers such as Google, IBM SoftLayer and Microsoft Azure provide similar mechanisms but with varying token types ranging for proprietary ones to some variant of OAuth. Similarly, if an enterprise decides to outsource its CRM system to Salesforce.com, Netsuite or SugarCRM, managing identity tokens becomes the first step towards interacting with such SaaS providers. Without a tested infrastructure that deals with consuming, generating and managing a variety of identity tokens, an enterprise is not positioned to realize the promise of cloud computing.
2. Message and Protocol Interoperability
Messages exchanged across or within API domains can be represented in HTML, JSON, XML, SOAP or EDI formats. A well structured message enables machine readability so that an application can extract necessary information. Consuming and generating messages readily and transforming messages across a variety of formats becomes a crucial aspect of a successful API deployment. The interoperability requirements are fundamentally at a message-level, both from a structural standpoint, e.g., changing RESTful JSON or XML messages into a SOAP message, as well as at a semantic-level, e.g., aggregating customer data from multiple source messages.
Protocol interoperability is a second fundamental requirement for interoperability in Federated API. Most communication across API domains is over HTTPS (or HTTP derivatives such as AS/2), while internally XML and SOAP messages may be exchanged with legacy mainframes using JMS or proprietary queues such as IBM MQ Series, or Tibco EMS. Interoperability between protocols is a necessary requirement for setting up a meaningful API domain that has deep integration with existing business processes running on legacy mainframes.
Implicaton on cloud computing: Corporations should be prepared for parsing and understanding a variety of message types before interacting with an external cloud. Parsing JSON, XML and SOAP, understanding services exposed as WSDLs, extracting and inserting attributes in HTTP headers and managing URL mappings are all critical for enabling cloud-computing within an enterprise. Without a well tested infrastructure deployed for Federated API, adding external API domains, such as a cloud provider, is prone to interoperability issues.
3. Message Hygiene
For the billions of messages of diverse formats that traverse an enterprise in a successful API deployment, determining whether a message made it to its designated target in the correct format and without any tampering or malicious changes is critical — a single lost message may be one too many. Identifying unhygienic messages and quarantining such messages for further analysis is essential in sustaining smooth business operation.
Fortunately, structured data such as JSON, XML and SOAP provide the ability to check for message hygiene through a variety of ways starting with the simplest check: XSD Schema Validation. A schema provides constrains for message data types, structure, and content (through facets). Enforcing schema validation for XML or simple deep-content inspection through regular expression for JSON in a centralized manner ensures that the messages adhere to their advertised structure. Message integrity checks via XML Signatures and verification enforcement provides an additional layer of sophistication for ensuring messages hygiene. Cloud vendors such as Amazon EC2 provide the ability to sign API calls used for provisioning and controlling virtual instance. This signature capability ensures that the messages have not been tampered with.
Implication on cloud computing: Message formats are advertised via RESTful API documentation (WADL lacks adoption) or via WSDLs for most SaaS providers. Consider a classic use-case where an enterprise uses SugarCRM, the leading provider of open source customer relationship management (CRM) software, deployed in the cloud as an off-premise SaaS model. The deployment of SugarCRM is available off-premise and the subscribing corporation can readily integrate, for example, their internally hosted order capture and fullfillment systems using a SugarCRM generated WSDL. Similar integration can take place using REST calls to cloud infrastructure providers such as Rackspace. All request and responses need to be checked for proper structure through schema validation or signature checks. Simple API version changes from a provider can have a dramatic effect on a corporation’s IT processes that heavily depend on cloud-based systems. Checking for message hygiene can pinpoint such issues and can serve as fundamental aspect of run-time API governance extended to cloud computing.
Conclusion
Cloud computing will not be properly adopted by large corporations that haven’t yet figured out a Federated API strategy. Without Federated APIs, domains are relegated to isolated silos. How can an enterprise be expected to outsource aspects of its core infrastructure without having the fundamentals requirements for Federated API: Federated Identity Management, Interoperability, and Message Hygiene addressed across the enterprise. Building Federated APIs is the pre-requiste for a successful, enterprise-class cloud strategy. Building a strong infrastructure for Federated API requires run-time API enforcement, monitoring and security through API Gateways, portal and service Authentication and Authorization decisions via Identity Management and sound API testing across diverse message types, identity tokens and API security standards.