Enterprise API Management

Design and deliver valuable business APIs

Luis Weir

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781787285613
• Edition: 1
• Topic: Computer Science
• Subtopic: Entreprise Applications
• Index: Computer Science

A strategy and implementation guide for building, deploying, and managing APIs

Key Features

• Comprehensive, end-to-end guide to business-driven enterprise APIs
• Distills years of experience with API and microservice strategies
• Provides detailed guidance on implementing API-led architectures in any business

Book Description

APIs are the cornerstone of modern, agile enterprise systems. They enable access to enterprise services from a wide variety of devices, act as a platform for innovation, and open completely new revenue streams.

Enterprise API Management shows how to define the right architecture, implement the right patterns, and define the right organization model for business-driven APIs.

Drawing on his experience of developing API and microservice strategies for some of the world's largest companies, Luis Weir explains how APIs deliver value across an enterprise. The book explores the architectural decisions, implementation patterns, and management practices for successful enterprise APIs, as well as providing clear, actionable advice on choosing and executing the right API strategy in your enterprise.

With a relentless focus on creating business value, Luis Weir reveals an effective method for planning, building, and running business products and services with APIs.

What you will learn

• Create API strategies to deliver business value
• Monetize APIs, promoting them through public marketplaces and directories
• Develop API-led architectures, applying best practice architecture patterns
• Choose between REST, GraphQL, and gRPC-style API architectures
• Manage APIs and microservices through the complete life cycle
• Deploy APIs and business products, as well as Target Operating Models
• Lead product-based organizations to embrace DevOps and focus on delivering business capabilities

Who this book is for

Architects, developers, and technology executives who want to deliver successful API strategies that bring business value.

Modern API Architectural Styles

This chapter complements Chapter 5, API-Led Architecture Patterns, by discussing in more detail the different modern API architectural styles, such as Representational State Transfer (REST), Graph Query Language (GraphQL), and Google Remote Procedure Calls (gRPC), that were briefly mentioned in the patterns illustrated. This chapter accomplishes this by first delivering a point of view on the application interface protocols and standards that have led to modern APIs. Next, the chapter will elaborate on their unique characteristics, their pros and cons, and when to (or not to) use each of them.

A brief history of interfaces

As mentioned in the Preface, the use of programming interfaces as the means for one application (or application module) to interact with another is by no means new. In fact, the first use of the term API can be traced back to the 1968 publication Data Structures and Techniques for Remote Computer Graphics by I. W. Cotton and F. S. Greatorex, Jr. The paper described an approach to achieving hardware abstraction, modularity, and reusability by implementing hardware-agnostic APIs that can be remotely accessed from multiple display devices.

For more information on this publication, please refer to the following link:
https://www.computer.org/csdl/proceedings/afips/1968/5072/00/50720533-abs.html

However, in spite of the obvious similarities with the contemporary use of interfaces, it is difficult to tell whether such early use of the term had any influence on how we employ APIs today. Regardless of this, what can be concluded without question is that the notion of interfaces as the means of achieving some form of abstraction has been present since the early days of computer science. Recognizing this is extremely important as it's clear evidence that APIs have and will continue to evolve. This will be the case even more so as faster, more efficient, and more compact hardware infrastructure, application communication protocols, and architecture paradigms are introduced to the industry.

This is one of the main reasons that this book has, to the extent possible, decoupled itself from just one API architectural style (for example, REST) and rather it focuses on the bigger picture, such as approaches, concepts, technical capabilities, and patterns that may also apply in the future, beyond APIs as we know them today.

The rise of RPC

Modern APIs are broadly considered to be an evolution of the Remote Procedure Call (RPC) protocol. Although research for the protocol started in the 1970s, it wasn't until the late 1980s, when Sun Microsystems (now part of Oracle Corporation) first released its UNIX-based RPC implementation, that the protocol gained wide popularity and adoption.

Please refer to the following article for further details: https://en.wikipedia.org/wiki/Remote_procedure_call#History_and_origins

The Open Network Computing (ONC) RPC, also referred to as Sun's RPC, had many of the characteristics expected of modern APIs:

• It made use of the External Data Representation (XDR) standard to define an interface that both server and client applications should comply with.
• It made use of XDR as the means to serialize and deserialize data over the wire (basically request and response messages).
• It made use of the still-widespread Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) as transport.

Figure 6.1: Modern APIs as perceived today

As illustrated in preceding diagram, modern APIs, such as RPC, also consist of a client application (the consumer of the API), a server (the producer of the API) and an interface definition document detailing, in technical terms, all the details of an interface, such as the actions/methods/resources supported and data inputs and outputs.

However, ONC RPC wasn't the only popular RPC implementation. The following diagram illustrates in chronological order the interface protocols and standards that followed and still apply today.

As can be seen, within five years of its inception, the Open Software Foundation (OSF), a non-profit organization originally consisting of Apollo Computer, Groupe Bull, Digital Equipment Corporation, Hewlett-Packard, IBM, Nixdorf Computer, and Siemens AG, (referred to as the Gang of Seven), released its own implementation of RPC called the Distributed Computing Environment (DCE) RPC.

Note that in February 1996, the OSF merged with X/Open to become The Open Group.

Figure 6.2: Application interfaces protocols and standards evolving through time

Although, at a conceptual level, DCE RPC shared many of the characteristics of ONC RPC, in actual practice there were many notable differences. For example, the former made use of an XDR standard as the means to define public interfaces and also to serialize and deserialize data over the network. The latter made use of its own interface definition language (IDL) and a network data representation (NDR) specification to serialize data into octet streams (a process known as marshaling) and then deserialize it (a process known as demarshaling).

Another difference was that DCE RPC did not limit the number of parameters on a call; in ONC RPC, on the other hand, calls were limited to one input and one output parameter.

All of the interface protocols and standards are described in detail in the following article:
https://www.soa4u.co.uk/2019/02/a-brief-look-at-evolution-of-interface.html

RPC and object-oriented programming

One important characteristic that both DCE and ONC RPC protocols had in common, though, was the fact that neither were based on the object-oriented programming model, which was increasingly gaining popularity in the early 1990s.

The first RPC-based protocol natively supporting the object-oriented programming model was the Common Object Request Broker Architecture (CORBA), created by the Object Management Group (OMG) consortium. CORBA, just like other RPC systems, followed a client-server architecture, with the major difference being that instead of serializing/deserializing flat data over the network, it adopted the Internet InterORB Protocol (IIOP) as a messaging protocol to transfer objects over a TCP/IP transport.

The Distributed Component Object Model (DCOM) was perhaps the second RPC-based protocol supporting the object-oriented programming model. DCOM was created by and remains the property of Microsoft. However of interest is the fact that DCOM made heavy use of Microsoft RPC (MSRPC), which is nothing but a modified version of DCE RPC but was originally created to support a client/server model in the Windows NT operating system.

It's worth noting that with the popularity of these proprietary protocols also came the emergence of a new set of tools in support of enterprise application integration (EAI). EAI tools made use of these protocols to enable the integration of different applications that could not otherwise talk to each other. Refer to Chapter 2, The Evolution of API Platforms, for a comprehensive overview of how EAI evolved into the modern platforms...

Table of contents

• Title Page
• Copyright and Credits
• About Packt
• Foreword
• Contributors
• Preface
• The Business Value of APIs
• The Evolution of API Platforms
• Business-Led API Strategy
• API-Led Architectures
• API-Led Architecture Patterns
• Modern API Architectural Styles
• API Life Cycle
• API Products' Target Operating Model