RESTful API Design - Best Practices in API Design with REST: API-University Series, #3

RESTful API Design

APIs your consumers will love

Matthias Biehl

RESTful API Design

RESTful API Design

Abstract

1 Introduction

1.1 What is an API?

1.2 Why APIs?

1.3 How are APIs used?

1.4 What is API Design?

1.5 What is the difference between API Design and API Architecture?

1.6 Why is API Design important?

1.7 Why should I build RESTful APIs?

1.8 Why do I need OpenAPI, Swagger or RAML?

1.9 How to put API Design into Practice?

2 Consumer-Oriented API Design: APIs as Products

2.1 APIs are Products

2.2 API Consumers

2.3 Consumer-Oriented APIs

2.4 Building Consumer-Oriented APIs

2.4.1 Identify the Prototypical API Consumers

2.4.2 Engage with API Consumers

2.4.3 Learn about the Solution Architecture of Consumers

2.5 Summary

3 API Design and Development Approach

3.1 Foundations

3.1.1 Consumer-Oriented Design Approach

3.1.2 Contract-First Design Approach

3.1.3 Agile Design Approach

3.1.4 Simulation-based Design

3.1.5 Conclusion

3.2 Design Approach

3.2.1 Overview

3.2.2 Phase 1: Domain Analysis

3.2.3 Phase 2: Architectural and Frontend Design

3.2.4 Phase 3: Prototyping

3.2.5 Phase 4: Implementation for Production

3.2.6 Phase 5: Publish

3.2.7 Phase 6: Maintenance

3.3 Discussion

3.3.1 Hand-over Points

3.3.2 Pre-Work vs. Actual Work

3.4 Summary

4 API Design with API Description Languages

4.1 What are API Description Languages?

4.2 Usage

4.2.1 Communication and Documentation

4.2.2 Design Repository

4.2.3 Contract Negotiation

4.2.4 API Implementation

4.2.5 Client Implementation

4.2.6 Discovery

4.2.7 Simulation

4.3 Language Features

4.4 Limitations

4.5 Summary

5 API Architectural Design Decisions

5.1 Requirements for APIs

5.1.1 Responsibilities of APIs

5.1.2 Desirable Properties of APIs

5.1.3 Summary

5.2 Architectural Patterns

5.2.1 Client-Server Patterns

5.2.2 Facade Pattern

5.2.3 Proxy Pattern

5.3 Architectural Styles

5.3.1 REST Style

5.3.2 HATEOAS Style

5.3.3 GraphQL Style

5.3.4 RPC Style

5.3.5 SOAP Style

5.3.6 Streaming Style

5.4 Architectural Trade-offs

5.4.1 RPC in Comparison to REST

5.4.2 HATEOAS in Comparison to REST

5.4.3 SOAP in Comparison to REST

5.5 Summary

6 Introduction to REST

6.1 HTTP

6.2 REST Concepts

6.2.1 Resource

6.2.2 API

6.2.3 Representation

6.2.4 Uniform Resource Interface

6.3 REST Constraints

6.4 State in REST

6.4.1 Application State

6.4.2 Resource State

6.4.3 Anti-Pattern: Using Token Attributes to Store Application State

6.4.4 Summary

6.5 Advantages of REST

6.6 HATEOAS Style

6.6.1 HATEOAS Concepts

6.6.2 HATEOAS Constraints

6.6.3 Advantages of HATEOAS

6.7 Summary

7 API Frontend Design Decisions

7.1 Resources

7.1.1 What is a Resource?

7.1.2 Instance Resources

7.1.3 Collection Resources

7.1.4 Controller Resources

7.1.5 Resource Ordering

7.1.6 Resource Granularity

7.1.7 Resource Relations

7.1.8 Resource Links

7.1.9 Best Practices for Resource Design

7.2 URI Design

7.2.1 Introduction

7.2.2 Recommendations

7.2.3 URI Template

7.2.4 Stable URIs

7.2.5 Nesting Depth

7.2.6 Maximum Length of URIs

7.2.7 URLs of Collections Resources

7.2.8 Relative URLs vs. Absolute URLs

7.3 Representations

7.3.1 Where can Representations be Found?

7.3.2 Content-Type of Representations

7.3.3 Addressing Representations

7.3.4 Content Negotiation

7.3.5 Data Size of Representations

7.3.6 Binary Data

7.3.7 JSON

7.4 Parameters

7.4.1 Use of Parameter Types

7.4.2 Parameter Types

7.5 Methods

7.5.1 Use of HTTP Methods

7.5.2 Meaning of HTTP Methods

7.5.3 Properties of HTTP Methods

7.6 Status Codes

7.6.1 Overview of HTTP Status Codes

7.6.2 Redirection

7.6.3 Error Handling

7.7 Input and Output Validation

7.7.1 Input Validation

7.7.2 Output Validation

7.8 Intuitive Use

7.8.1 Consistent Names and Naming Schemes

7.8.2 Summary

7.9 Integration

7.9.1 Cross-Origin Resource Sharing (CORS)

7.9.2 Browser Exploration

7.9.3 Robustness

7.9.4 Discovery

8 OpenAPI/Swagger for API Frontend Design

8.1 Introduction

8.2 Root Element

8.3 Resources

8.4 Schema

8.5 Parameters

8.6 Reusable Elements

8.7 Security

8.7.1 Security Definition

8.7.2 Security Binding

9 RAML for API Frontend Design

9.1 Introduction

9.2 Root Element

9.3 Schema

9.4 Parameters

9.4.1 Path Parameters

9.4.2 Query Parameters

9.4.3 Form Parameters

9.4.4 Header Parameters

9.5 Reusable Elements

9.5.1 External Elements: Inclusion of Files

9.5.2 Internal Elements: Definition of Resource Types and Traits

9.5.3 Internal Elements: Usage of Resource Types and Traits

9.6 Security

10 API Backend Design Decisions

10.1 Backends

10.2 Transformations

10.2.1 Transformation Source and Target

10.2.2 Transformation Tasks

10.2.3 Transformation Tools

10.3 Dealing with Backend Errors

10.4 Logging

10.4.1 Sanitizing Logged Data

10.4.2 Require a Transaction ID / Request ID / Tracking ID

11 Non-Functional Properties of APIs

11.1 Security

11.1.1 The Appropriate Level of Security

11.1.2 Security Concerns

11.1.3 Security Mechanisms

11.1.4 Security Best Practice

11.2 Performance and Availability

11.2.1 Caching

11.2.2 Traffic Shaping

11.2.3 Pagination

11.2.4 Enable Content Compression

11.2.5 Remove Whitespace from Responses

11.3 Caching

11.3.1 Use Cases for Caching

11.3.2 Caching Mechanisms

11.3.3 HTTP Caching Mechanism with Conditional Requests

11.4 Traffic Shaping

11.4.1 Use Cases for Traffic Shaping

11.4.2 Mechanisms for Traffic Shaping

11.5 Evolution and Versioning

11.5.1 The Evolution Challenge

11.5.2 Publication: The Root Cause of the Evolution Challenge

11.5.3 Types of API Evolution

11.5.4 Anticipating and Avoiding Evolution

11.5.5 Coping with Evolution - Versioning

11.5.6 Supporting Multiple Versions Simultaneously

12 API Client Design

12.1 Designing the Solution

12.1.1 Functionality in the Client or in the API?

12.1.2 Use an existing API or build a new API?

12.1.3 How to choose a third party API?

12.2 Discovering APIs

12.2.1 Consumer Discovery

12.2.2 Automatic Discovery

12.3 Calling APIs

12.3.1 Prepare and Send the API Request

12.3.2 Process the API Response

13 Appendix

Newsletter with FREE Bonus Material

About the Author

Feedback

Other Products by the Author

API-University Book Club

Book on OAuth 2.0

Book on OpenID Connect

Book on API Architecture

Book on RESTful API Design

Book on Webhooks

Book on GraphQL API Design

Book on REST & GraphQL

Book on Serverless GraphQL APIs with AWS AppSync

Book on Making Money with Alexa Skills - A Developer’s Guide

Online Course on OAuth 2.0

Online Course on RESTful API Design

14 Typical Content-Types

15 HTTP Methods

16 HTTP Headers

17 HTTP Status Codes

References

Table of contents

RESTful API Design

RESTful API Design

Copyright 2016 by Matthias Biehl

All rights reserved, including the right to reproduce

this book or portions thereof in any form whatsoever.

Biehl, Matthias

API-University Press

Volume 3 of the API-University Series.

Includes illustrations, bibliographical references and index.

ISBN-13: 978-1514735169

ISBN-10: 1514735164

API-University Press

https://www.api-university.com

[email protected]

Abstract

Looking for Best Practices in RESTful APIs?

This book is for you! Why? Because this book is packed with best practices on many technical aspects of RESTful API Design, such as the correct use of resources, URIs, representations, content types, data formats, parameters, HTTP status codes, and HTTP methods.

You want to design and develop APIs like a Pro? Use API description languages to both design APIs and develop APIs efficiently. The book introduces the two most common API description languages RAML and OpenAPI/Swagger.

Your APIs connect to legacy systems? The book shows best practices for connecting APIs to existing backend systems.

You expect lots of traffic on your API? The book shows you how to achieve high security, performance, availability and smooth evolution and versioning.

Your company cares about its customers? Learn a customer-centric design and development approach for APIs, so you can design APIs as digital products.

One more thing before we get started ...

As a reader of this book, you have free access to the API-University Best Practice Newsletter. Free bonus material and amazing freebies are waiting for subscribers, such as the popular OAuth Cheat Sheet.

1 Introduction

1.1 What is an API?

Software is typically used by people like you and me via a user interface. Increasingly, however, software is not only used by people, but also by other software applications. This requires another type of interface, an Application Programming Interface, in short API.

APIs offer a simple way for connecting to, integrating with and extending a software system. More precisely, APIs are used for building distributed software systems, whose components are loosely coupled. The APIs studied here are web-APIs, which deliver data resources via a web technology stack. Typical applications using APIs are mobile apps, cloud apps, web applications or smart devices.

The charm of APIs is that they are simple, clean, clear and approachable. They provide a reusable interface that different applications can connect to easily. However, APIs do not offer a user interface, they are usually not visible on the surface and typically no end user will directly interact with them. Instead, APIs operate under the hood and are only directly called by other applications. APIs are used for machine to machine communication and for the integration of two or more software systems.

The only people interacting with APIs directly are the developers creating applications or solutions with the APIs. This is why APIs need to be built with the developers in mind, who will integrate the APIs into new applications. This insight explains, why a new perspective is required for building APIs.

1.2 Why APIs?

An API offers a simple way for connecting to, integrating with and extending software systems. Now, think about the entities that are run by software. Businesses, markets and banks are run by software. Industrial production processes are controlled by software. Machines, cars and many consumer products contain software. However, these software systems are typically isolated and functionality of one system cannot be accessed from the other system. APIs provide a possibility to connect these separate software entities. APIs provide the capabilities which are essential for connecting, extending and integrating software. And by connecting software, APIs connect businesses with other businesses, businesses with their products, services with products or products directly with other products.

The infrastructure for enabling this connection is already in place. Each and every person, each employee and each customer has a smart, internet-enabled device, businesses have websites and web-services. Even an increasing number of the products sold by the businesses carry digital sensors and are internet enabled. All these devices are connected to the internet and can – in principle – be connected via APIs.

Just one example for the business to business integration: The business of an enterprise can be expanded by linking the business to partners up and down the value chain. Since businesses are run by IT, the businesses can be better linked by integrating the IT systems of a business up and down the value chain to the IT systems of other businesses, partners, employees and to customers. This can be accomplished if the IT systems of the business partners are linked via services.

An enterprise cannot force its business partners to use its services. But it can make these services so good – so valuable and simple – that the business partners will want to use them. If these services are good, they can become a means for retaining existing partners and a means for obtaining new partners. But what makes a service good? In this context a service is good ...

... if it is valuable and helps the partners perform their business.

... if it fits the exact needs of the partners.

... if it is simple to understand.

... if it is easy to integrate and monitor for the partners.

... if it is secure, reliable and meets the performance requirements.

APIs should fulfill all of the above conditions. This is why they are used for both external integration with business partners and for internal integration within the company. Amazon, for example, uses APIs internally, to integrate the IT systems of its departments. If the interfaces and technology are already in place for internal integration, it becomes easier to provide external integration. External integration is used with business partners or external entities. External APIs are also necessary for realizing mobile apps. Interesting mobile apps use company data, data that is delivered to the app via APIs.

Another reason for using APIs is their use as an innovation lab of the enterprise. To fulfill this vision, the API portfolio should enable the enterprise to build innovative apps with little effort and spark creativity. By making company assets easily available through API, new uses of these assets can be found. Since APIs provide a new, simple way for accessing company assets, assets can be used in new ways within the company. Providing external access to the assets of your organization via APIs, enables external third party developers to create innovations for your organization by using your organization’s assets.

1.3 How are APIs used?

APIs are one component in a typical internet solution. A typical internet solution consists of an app, APIs and backend systems. The app is offered to end users. However, the end-user does not call the API directly. Instead, the API is called by the app.

Figure 1.1: API-based Solutions

As shown in Figure 1.1, an API-based solution typically consists of:

A client or app (mobile app, web app, cloud app, TV app or IoT device) that calls the APIs and processes the data provided by the APIs. This client is responsible for the end user experience.

A number of APIs that provide data to the app.

An API platform that manages the APIs and connects the API to the backend systems.

Backend systems, which implement the business logic, store the data or run the algorithms.

1.4 What is API Design?

Any type of design requires taking well-informed decisions. The decisions are intended to make the product better in some way, e.g. provide more functionality, provide better quality or a better user experience. Better design decisions typically lead to better products. This is no different when designing APIs. Which design decisions are there for APIs? We see four groups of design decisions.

Architectural Design Decisions: When designing an API, decisions have to be made regarding architectural issues, such as the patterns and the styles to be used. Should the API follow the REST or SOAP architectural style? These design decisions are foundational and have an impact on all following decisions. We will address architectural design decisions for APIs in chapter 5.

API Frontend Design Decisions: Since the frontend of the API is visible to the API consumers (= customers of the API), frontend design decisions are quite critical for the success of an API. Frontend design for APIs is typically RESTful design. For RESTful frontend design we need to answer questions such as: How does the URI of the API look like? Are the parameters passed in the form of query parameters or path parameters? Which headers and status codes should be used? We will address frontend design decisions for APIs in chapter 7.

API Backend Design Decisions: The functionality of the API depends on leveraging data and services of backend systems. Backend design decisions address the connection between API and backend. Design decisions regarding the integration, transformation, aggregation, security and error handling of the backend have an impact on the functionality of the API. We will address backend design decisions for APIs in chapter 10.

Non-functional Design Decisions: The architectural, frontend and backend design decisions are primarily taken to craft the functionality of the API. However, these decisions also have an impact on the non-functional properties of the API, such as security, performance, availability, and evolvability. Non-functional properties of the API should not be an afterthought. The API needs to be designed right from the start to fulfill non-functional requirements. We will address non-functional design decisions for APIs in chapter 11.

In this book we address all four groups of design decisions for APIs. The focus is, however, on REST and the API frontend design decisions.

1.5 What is the difference between API Design and API Architecture?

In general, API architecture spans the bigger picture of APIs and can be seen from several perspectives:

API architecture may refer to the architecture of the complete solution, consisting not only of the API itself, but also of an API client such as a mobile app and several other components. API solution architecture explains the components and their relations within the software solution.

API architecture may refer to the technical architecture of the API platform. When building, running and exposing not only one, but several APIs, it becomes clear that certain building blocks of the API, runtime functionality and management functionality for the API need to be used over and over again. An API platform provides an infrastructure for developing, running and managing APIs.

API architecture may refer to the architecture of the API portfolio. The API portfolio contains all APIs of the enterprise and needs to be managed like a product. API portfolio architecture analyzes the functionality of the API and organizes, manages and reuses the APIs.

API architecture may refer to the design decisions for a particular API. This is what we usually refer to as API proxy architecture. It includes architectural design decisions, non-functional design decisions, frontend and backend design decisions. To document these design decisions, API description languages are used.

So, what is the difference between API architecture and API design? API design is one aspect of API architecture. API architecture has a wider scope, considering also the API solution, API platform and API portfolio. In a way, the API architecture defines the frame, in which API design can take place and does make sense.

API design can only be effective if the overall API architecture is already in place. In this book we assume that this is the case and focus only on the aspect of API design. If you are interested in the big picture of API architecture, I recommend the book API Architecture from the API-University Series (Biehl 2015b).

1.6 Why is API Design important?

For a moment, picture the Golden Gate Bridge. I think you would agree, that it is very hard to move the pillars of such a bridge, which is made of steel and concrete. Such changes would be difficult, costly and time intensive. This is why engineers design a blueprint before building the bridge. The design allows for planning all the details, iterating over several proposals and performing what-if analysis. Changes to the design are easy and cheap to perform. And by making changes to the design, it hopefully becomes unnecessary to make changes to the real artifacts. The same is true for APIs.

When APIs have already been built, changes are difficult, expensive and time-intensive. Even worse, the changes to published APIs might break any clients using the API. The consumers might get upset and switch the API provider. To avoid this scenario, the API needs to be right from the start, by the first time it is published, and API design can contribute to this goal.

An appropriate API frontend design enables a contract-first design approach. Once the frontend design is externalized and written down (e.g. in RAML or OpenAPI/Swagger), it can be used not only by the API providers to implement the API proxy, but also by API consumers to build apps with this API. The API consumer does not have to wait for the API to be finished, but development of API and app can proceed in parallel.

Non-functional properties of the API should not be an afterthought. The API needs to be designed right from the start to fulfill all non-functional properties such as security, performance and availability.

API design forces us to think about the API before we build it. It helps us to avoid building the wrong API, or building the API in the wrong way. Building APIs in the wrong