Sabre's API Strategy

Introduction

Application programming interfaces -APIs- (sometimes referred to as web services) are a core element of any digital business platform. APIs provide the interfaces between applications, data and services. These interfaces enable the connection between people, businesses and things. With proper management, APIs can be an enabler for innovation, faster development of digital products and new business models.

Sabre adopted an "API First" management approach, leveraging industry best practices in terms of developing and exposing APIs for both internal and external consumption.

The Sabre API Strategy outlines the direction for management, design and development of APIs in Sabre following these two core product patterns. The Sabre REST API Guidelines is an accompanying document containing recommendations for REST API design.

The Sabre Way: Our API-Strategy (TL;DR)

API-First

API-First is a mindset for treating APIs as the products that drive our business. Companies embracing an API-first mindset behave differently:

We deliver APIs as the initial user interface.
We serve as "customer zero" for our APIs.
We treat APIs as products. A key factor to enable the evolution of an API platform is treating APIs as products.

Developer Experience

Developer Experience (DX) springs from an obsessive focus on customer needs. We know our users are highly technical, knowledgeable, and demanding. We strive to meet them where they are:

Delivering REST/JSON.
Designing via OpenAPI Spec files.
Leveraging a common set of REST API design guidelines.
Collaborating with users.
Publishing premiere docs on Dev Studio.

A True Platform

Success comes from working effectively as a team by breaking down silos and crossing domains. We make it look like all APIs are coming from the same company:

Requests, responses, data concepts, and errors feel familiar across all Sabre APIs.
Services exist to solve unique and valuable problems without confusing overlaps.
Build something people want.

API Platform

At the center of our API strategy is Sabre's API Platform which exposes a significant part of Sabre's data and functionality through APIs. The platform is a layered architecture with clearly defined infrastructure capabilities shared by all products. Its goal is to be flexible enough to meet current and future business needs through extension, composition and orchestration of microservices.

Key characteristics of the API platform:

New and existing Product capabilities are taken to market with a Platform First Strategy (API enabled). See API first.
Sabre as customer "zero". We are customer “zero” for the services exposed on the Sabre API Platform. User Experiences (UXs) are powered by Sabre APIs and are separated from underlying business logic, but front-end products also contribute to the platform when API enabled.
We treat APIs as first-class citizens. See API first.
Well crafted, secure APIs. The APIs in the platform should be crafted according to industry standards with high emphasis on security.
Exposed with leap forward technology. Sabre launched its first set of SOAP/XML services in 2004, we have come a long way since then and explored diversifying to alternate technologies. Since 2014 we have invested in REST/JSON (or JSON over HTTP) as the API industry shifted towards this modern technology. Today REST/JSON (JSON over HTTP) is our standard choice when exposing new capabilities. In other words, we are putting a stop to the development of new capabilities via SOAP/XML*. Of course, we are looking at new technologies as they are adopted by the API community.

Note*: Exception applies to cases where we deliver content to comply with industry standards such as IATA’s NDC which is XML.

API discoverability. Which APIs exist in the platform and what capabilities they have should be easy to discover for API consumers.
Developer experience (DX). The user experience for developers (a.k.a. developer experience) is key for adoption of any API. A good DX requires well designed APIs, complete API documentation, self-service-based access, useful error messages, and predictability in operations, among others.

Our reference architecture unifies how we develop software within Sabre:

Sabre API PLatform

Business Services Layer

The Business Services Layer (a.k.a. API Orchestration Layer) is an abstraction layer that takes generically modeled data elements and/or features from downstream domains in the platform and prepares them in a more specific way for a targeted developer persona or application.

Characteristics of a business services layer:

Orchestration: Orchestration’s core value is when multiple API services need to be coordinated to achieve a business outcome. API orchestration typically requires creating a single API that offers valuable functions to its consumers, often by making multiple calls to multiple different services to respond to a single API request.
Simplification: Simplification implies managing data formatting between separate services, applying default values for commonly required data elements or hiding unimportant data unless specifically requested.
Abstraction: Abstraction entails reducing complexity in the services we expose, by taking complexity into our implementation as we orchestrate services built by different domains, which may have been built in different technologies (XML, JSON) and even during different periods of time (following different design standards).

Principles that need to be considered when building an business/orchestration layer:

Outside-in approach (customer centric)
- Most APIs are designed by API providers with the goal of maintaining data model purity. When building services on a business services layer, we must be prepared to sometimes abandon purity in favor of optimizations and/or performance.
- Many APIs are designed by API teams to make support/maintenance easier for the internal API team. When building services on a business services layer, we must be prepared to potentially add complexity for the API team (or other teams, depending on the way it is implemented).
While this sounds undesirable for our internal teams, the overarching goal is to dramatically improve efficiency and/or simplicity for API consumers (ease-of-integration) at some mild cost to the API team.
Cross-domain orchestration

Creating a service in the Business Services Layer via orchestration of different services should only be done when combining services from different domains (a.k.a. cross-domain orchestration).

If orchestration is required to achieve a business outcome and the components (services) to be orchestrated reside within a single logical area/domain, then it’s the area/domain’s responsibility to orchestrate the solution (assuming the business value is justified). These are cases where the business services layer will not build unnecessary logic in its layer.
Interface vs Implementation

As stated previously, the business services layer serves as an abstraction layer from how Sabre operates at the Platform/Infrastructure level, this allows Sabre to architect the services in the business services layer in a way where the Interface of the API is decoupled from the Implementation.

Decoupling interface from implementation allows API teams to perform technical modernization / re-platform work maintaining the same API interface. This provides additional value to the API consumers who only need to code to a single interface, which in turns ensures that Sabre has control as to when API consumers are migrated (e.g., cases where the original service implementation connects to a system deemed "legacy" and a replacement/modern/lower-cost system is available).

Examples of services exposed in this layer:

Platform Services Layer

The Platform Services layer consists of core services exposed by individual domains to allow other systems access their capabilities. An example of this could be the depicted as CRUD operations being exposed from a specific domain, these services are generic in nature and do not address individual customer’s business problems, but rather are exposed as the platform’s lowest level service interfaces.

Services exposed as part of the Platform Services layer are normally conceived with an inside-out approach, taking as a foundation of their design the standard methods to access already available resources, or on an internal presupposition about what developers and end users might want or need.

Examples of services exposed in this layer:

Low-level services (LLSRQ)

Sabre REST API Design Guidelines

Vision

The Sabre REST API Design Guidelines advocates for easy-to-use, intuitive, and consistent APIs by implementing governance and collaboration across Sabre’s technology and product teams.

Our goal is to provide a collection of useful answers for the following design thinking question:

"How might we make it look like all of our APIs are coming from the same company?"

Developers using our APIs will form opinions, and we want those opinions to be positive ones. Our vision is to intentionally create a high-quality developer experience for external users as well as internal ones.

Improving API Design Across the Company

Sabre’s API-first design system and governance process enables us to provide a premiere technology platform leveraging industry best practices throughout our culture. Valuable benefits of our dedicated practice include:

Connecting experienced API designers with colleagues across the company.
Reducing API development time by leveraging shared conventions, tools, documents, and expert coaching.
Improving user efficiency through a focus on developer experience.
Empowering new API designers to accelerate in the right direction.
Decreasing customer support costs by improving quality via automation, reuse, and a foolproof process.

The North Star strategy is increasing usability of our APIs through consistent design, shared tooling, and coaching across our software architecture organization. Ideally, we’ll increase our API adoption offering new ways to integrate services, consume content, and expand the realized value of our overall platform.

Enabling API Designers

Sabre’s API design system and practice offers a highly curated self-serve library of valuable educational content. We encourage API designers to dive into the material most suited for their needs. This includes content such as:

Data Type Taxonomy – collecting several typical data concepts into a reusable "parts inventory" for rapidly assembling JSON payloads.
JSON Payloads – giving guidance on approaching human-centered design for request and response payloads.
Secure API Design – offering advice for keeping API interface security top of mind.
RESTful and RPC API Style Guides – defining best practices for creating resource-oriented, and command-oriented, web services while avoiding common pitfalls.
OpenAPI Spec File Authoring Tips - listing practical advice for writing better OAS files.

Organizing API Design with Purpose

We have assembled an API Center of Practice and Design Governance consisting of our most experienced API experts and enthusiasts from across the company. The team’s mission is advocating for API design consistency across our entire collection of REST/JSON services. Team members do this through several ongoing activities:

Ensuring stakeholders understand the customer need for adhering to conventions through wide adoption of recommendations.
Coaching API designers on quality through dedicated sessions and training workshops.
Reviewing API designs through a lightweight approval process.

The effort is truly inclusive. Everyone in our company is welcome to observe and support the creation, improvement, and application of API design consistency in the spirit of transparency. We invite collaboration from the larger group of all Sabre colleagues interested in making APIs better in the service of a fantastic developer experience.