Bibliography DevOps DevSecOps-Security-Privacy Software Engineering


See: API Testing and Development with Postman: A practical guide to creating, testing, and managing APIs for automated software testing

Fair Use Source:

Bibliography JavaScript Software Engineering


See: REST API Development with Node.js: Manage and Understand the Full Capabilities of Successful REST Development 2nd ed. Edition

Fair Use Source:

Bibliography Django Web Framework Python


See: Django for APIs: Build web APIs with Python and Django

Fair Use Source:

Bibliography Django Web Framework JavaScript Python React


See: Building Versatile Mobile Apps with Python and REST: RESTful Web Services with Django and React 1st ed. Edition

Fair Use Source:



See: Kubernetes Operators: Automating the Container Orchestration Platform 1st Edition

See also Kubernetes and Cloud Native

Fair Use Source:



See: Programming Kubernetes: Developing Cloud-Native Applications 1st Edition

See also Kubernetes and Cloud Native

Fair Use Source:



See: Kubernetes API Reference: From the OpenAPI specification version v1.19 Paperback – August 26, 2020

See also Kubernetes and Cloud Native

Fair Use Source:

Bibliography Cloud Software Engineering

The Design of Web APIs

See also: API, API Bibliography – Application Programming Interface Books and References

See: The Design of Web APIs, 1st Edition, by Arnaud Lauret, 1617295108 (DWAPI)

Fair Use Source: 1617295108 (DWAPI)

About This Book:

Web APIs are everywhere, giving developers an efficient way to interact with applications, services, and data. Well-designed APIs are a joy to use; poorly-designed APIs are cumbersome, confusing, and frustrating.

The Design of Web APIs is a practical, example packed guide to crafting extraordinary web APIs. Author Arnaud Lauret demonstrates fantastic design principles and techniques you can apply to both public and private web APIs.


“Assembles the fundamental building blocks of API design in an easyto-access way, and walks you through the vast landscape in a friendly and comfortable manner.” — From the Foreword by Kin Lane, The API Evangelist

“Answers nagging and complicated questions with a simple philosophy, but never tries to hide anything from you. A fantastic introduction to the field.” — Bridger Howell,

“An excellent guidebook for establishing a path to RESTful APIs.” — Shawn Smith, Penn State University

“Combines real-world examples with difficult abstract ideas.” — Shayn Cornwell, XeroOne Systems

About the Author:

Arnaud Lauret is a software architect with 15 years of experience in the banking industry. He has spent a decade using, designing, and building APIs. He’s known on the web as the API Handyman ( and is the creator of the API Stylebook (, a collection of resources for API designers.

Book Details:

  • ISBN-10: 1617295108
  • ISBN-13: 978-1617295102
  • Publisher: Manning Publications; 1st edition (November 6, 2019)
  • Paperback: 400 pages

Table of Contents:

Contents in brief:

Part 1: Fundamentals of API design Chapter 1: What is API design?

Chapter 2: Designing an API for its users

Chapter 3: Designing a programming interface

Chapter 4: Describing an API with an API description format

Part 2: Usable API design Chapter 5: Designing a straightforward API

Chapter 6 : Designing a predictable API

Chapter 7: Designing a concise and well-organized API

Part 3: Contextual API design Chapter 8: Designing a secure API

Chapter 9: Evolving an API design

Chapter 10: Designing a network-efficient API

Chapter 11: Designing an API in context

Chapter 12: Documenting an API

Chapter 13: Growing APIs

Contents in Detail:




contents in brief





about this book Who should read this book

How this book is organized: a roadmap

About the code

liveBook discussion forum

Other online resources

about the author

about the cover illustration

Part 1: Fundamentals of API design Chapter 1: What is API design? 1.1 What is an API? 1.1.1 An API is a web interface for software

1.1.2 APIs turn software into LEGO® bricks

1.2 Why API design matters 1.2.1 A public or private API is an interface for other developers

1.2.2 An API is made to hide the implementation

1.2.3 The terrible consequences of poorly designed APIs

1.3 The elements of API design 1.3.1 Learning the principles beyond programming interface design

1.3.2 Exploring all facets of API design


Chapter 2: Designing an API for its users 2.1 The right perspective for designing everyday user interfaces 2.1.1 Focusing on how things work leads to complicated interfaces

2.1.2 Focusing on what users can do leads to simple interfaces

2.2 Designing software’s interfaces 2.2.1 Viewing an API as software’s control panel

2.2.2 Focusing on the consumer’s perspective to create simple APIs

2.3 Identifying an API’s goals 2.3.1 Identifying the whats and the hows

2.3.2 Identifying inputs and outputs

2.3.3 Identifying missing goals

2.3.4 Identifying all users

2.3.5 Using the API goals canvas

2.4 Avoiding the provider’s perspective when designing APIs 2.4.1 Avoiding data influences

2.4.2 Avoiding code and business logic influences

2.4.3 Avoiding software architecture influences

2.4.4 Avoiding human organization influences

2.4.5 Detecting the provider’s perspective in the API goals canvas


Chapter 3: Designing a programming interface 3.1 Introducing REST APIs 3.1.1 Analyzing a REST API call

3.1.2 Basic principles of HTTP

3.1.3 Basic principles of REST APIs

3.2 Transposing API goals into a REST API 3.2.1 Identifying resources and their relationships with the API goals canvas

3.2.2 Identifying actions and their parameters and returns with the API goals canvas

3.2.3 Representing resources with paths

3.2.4 Representing actions with HTTP

3.2.5 REST API and HTTP cheat sheet

3.3 Designing the API’s data 3.3.1 Designing concepts

3.3.2 Designing responses from concepts

3.3.3 Designing parameters from concepts or responses

3.3.4 Checking parameter data sources

3.3.5 Designing other parameters

3.4 Striking a balance when facing design challenges 3.4.1 REST trade-off examples

3.4.2 Balancing user-friendliness and compliance

3.5 Understanding why REST matters for the design of any API 3.5.1 Introducing the REST architectural style

3.5.2 The impact of REST constraints on API design


Chapter 4: Describing an API with an API description format 4.1 What is an API description format? 4.1.1 Introducing the OpenAPI Specification (OAS)

4.1.2 Why use an API description format?

4.1.3 When to use an API description format

4.2 Describing API resources and actions with OAS 4.2.1 Creating an OAS document

4.2.2 Describing a resource

4.2.3 Describing operations on a resource

4.3 Describing API data with OpenAPI and JSON Schema 4.3.1 Describing query parameters

4.3.2 Describing data with JSON Schema

4.3.3 Describing responses

4.3.4 Describing body parameters

4.4 Describing an API efficiently with OAS 4.4.1 Reusing components

4.4.2 Describing path parameters


Part 2: Usable API design Chapter 5: Designing a straightforward API 5.1 Designing straightforward representations 5.1.1 Choosing crystal-clear names

5.1.2 Choosing easy-to-use data types and formats

5.1.3 Choosing ready-to-use data

5.2 Designing straightforward interactions 5.2.1 Requesting straightforward inputs

5.2.2 Identifying all possible error feedbacks

5.2.3 Returning informative error feedback

5.2.4 Returning exhaustive error feedback

5.2.5 Returning informative success feedback

5.3 Designing straightforward flows 5.3.1 Building a straightforward goal chain

5.3.2 Preventing errors

5.3.3 Aggregating goals

5.3.4 Designing stateless flows


Chapter 6 : Designing a predictable API 6.1 Being consistent 6.1.1 Designing consistent data

6.1.2 Designing consistent goals

6.1.3 The four levels of consistency

6.1.4 Copying others: Following common practices and meeting standards

6.1.5 Being consistent is hard and must be done wisely

6.2 Being adaptable 6.2.1 Providing and accepting different formats

6.2.2 Internationalizing and localizing

6.2.3 Filtering, paginating, and sorting

6.3 Being discoverable 6.3.1 Providing metadata

6.3.2 Creating hypermedia APIs

6.3.3 Taking advantage of the HTTP protocol


Chapter 7: Designing a concise and well-organized API 7.1 Organizing an API 7.1.1 Organizing data

7.1.2 Organizing feedback

7.1.3 Organizing goals

7.2 Sizing an API 7.2.1 Choosing data granularity

7.2.2 Choosing goal granularity

7.2.3 Choosing API granularity


Part 3: Contextual API design Chapter 8: Designing a secure API 8.1 An overview of API security 8.1.1 Registering a consumer

8.1.2 Getting credentials to consume the API

8.1.3 Making an API call

8.1.4 Envisioning API design from the perspective of security

8.2 Partitioning an API to facilitate access control 8.2.1 Defining flexible but complex fine-grained scopes

8.2.2 Defining simple but less flexible coarse-grained scopes

8.2.3 Choosing scope strategies

8.2.4 Defining scopes with the API description format

8.3 Designing with access control in mind 8.3.1 Knowing what data is needed to control access

8.3.2 Adapting the design when necessary

8.4 Handling sensitive material 8.4.1 Handling sensitive data

8.4.2 Handling sensitive goals

8.4.3 Designing secure error feedback

8.4.4 Identifying architecture and protocol issues


Chapter 9: Evolving an API design 9.1 Designing API evolutions 9.1.1 Avoiding breaking changes in output data

9.1.2 Avoiding breaking changes to input data and parameters

9.1.3 Avoiding breaking changes in success and error feedback

9.1.4 Avoiding breaking changes to goals and flows

9.1.5 Avoiding security breaches and breaking changes

9.1.6 Being aware of the invisible interface contract

9.1.7 Introducing a breaking change is not always a problem

9.2 Versioning an API 9.2.1 Contrasting API and implementation versioning

9.2.2 Choosing an API versioning representation from the consumer’s perspective

9.2.3 Choosing API versioning granularity

9.2.4 Understanding the impact of API versioning beyond design

9.3 Designing APIs with extensibility in mind 9.3.1 Designing extensible data

9.3.2 Designing extensible interactions

9.3.3 Designing extensible flows

9.3.4 Designing extensible APIs


Chapter 10: Designing a network-efficient API 10.1 Overview of network communication concerns 10.1.1 Setting the scene

10.1.2 Analyzing the problems

10.2 Ensuring network communication efficiency at the protocol level 10.2.1 Activating compression and persistent connections

10.2.2 Enabling caching and conditional requests

10.2.3 Choosing cache policies

10.3 Ensuring network communication efficiency at the design level 10.3.1 Enabling filtering

10.3.2 Choosing relevant data for list representations

10.3.3 Aggregating data

10.3.4 Proposing different representations

10.3.5 Enabling expansion

10.3.6 Enabling querying

10.3.7 Providing more relevant data and goals

10.3.8 Creating different API layers


Chapter 11: Designing an API in context 11.1 Adapting communication to the goals and nature of the data 11.1.1 Managing long processes

11.1.2 Notifying consumers of events

11.1.3 Streaming event flows

11.1.4 Processing multiple elements

11.2 Observing the full context 11.2.1 Being aware of consumers’ existing practices and limitations

11.2.2 Carefully considering the provider’s limitations

11.3 Choosing an API style according to the context 11.3.1 Contrasting resource-, data-, and function-based APIs

11.3.2 Thinking beyond request/response- and HTTP-based APIs


Chapter 12: Documenting an API 12.1 Creating reference documentation 12.1.1 Documenting data models

12.1.2 Documenting goals

12.1.3 Documenting security

12.1.4 Providing an overview of the API

12.1.5 Generating documentation from the implementation: pros and cons

12.2 Creating a user guide 12.2.1 Documenting use cases

12.2.2 Documenting security

12.2.3 Providing an overview of common behaviors and principles

12.2.4 Thinking beyond static documentation

12.3 Providing adequate information to implementers

12.4 Documenting evolutions and retirement


Chapter 13: Growing APIs 13.1 The API lifecycle

13.2 Building API design guidelines 13.2.1 What to put in API design guidelines

13.2.2 Continuously building guidelines

13.3 Reviewing APIs 13.3.1 Challenging and analyzing needs

13.3.2 Linting the design

13.3.3 Reviewing the design from the provider’s perspective

13.3.4 Reviewing the design from the consumer’s perspective

13.3.5 Verifying the implementation

13.4 Communicating and sharing



List of Figures

List of Tables

List of Listings


“For over a decade, API design has always meant REST to most developers. This reality has been constructed through regular waves of books and API-centered blogs that push RESTful design belief systems, leaving the discipline very focused and often times dogmatic. The Design of Web APIs by Arnaud Lauret is the beginning wave of the next generation of API design guidance, which will help us transcend this reality that has held us back for over a decade. His pragmatic approach to API design is still rooted in REST, but he has worked hard to bring real world API design knowledge to the table—minus the usual dogma.” (DWAPI)

Lauret takes us through the fundamentals of API design that you can easily find in other industry books, but he assembles the fundamental building blocks of this discipline in a very easy-to-access way and walks you through the vast landscape in a friendly and comfortable manner. I have known Arnaud personally for several years and consider him among a handful of top tier API talent that don’t just understand how you do APIs technically, but also understand the human-centered challenges of delivering APIs and how APIs can positively or negatively impact your API experience among developers. Arnaud focuses his knowledge on not just the act of designing an API, but also the act of providing a well-designed API for your intended audience in a thoughtful way.

I have personally watched Arnaud sit in the front row of hundreds of API talks around the globe, absorbing the best-of-breed API wisdom. One just needs to visit his Twitter timeline or to follow the hashtag for a popular API event to understand what I am talking about. He has a unique approach to listening to API industry speakers, processing the API information they are sharing, while also live-tweeting the most important points of the talk as a steady stream of API insights. It makes me happy to see Arnaud take this accumulated knowledge and put it down in book form, continuing his approach to not just sharpening his own skills, but also making sure he is sharing what he knows and his unique approach to API design with the world. Arnaud is a rare breed of API analyst that listens, cares, understands, and distills API knowledge down into usable building blocks you can actually put to work in your business world.

After the API design world began to pick up momentum after 2012 and the OpenAPI (FKA Swagger) began to grow in dominance, Arnaud was one of just a handful of API experts who worked hard to understand the potential of this specification, while also developing innovative tooling and visualizations around the open source API specification standard. Doing the hard work to understand not just the specification, but how it can embody, represent, and even govern many of the API design principles you need to be successful in the space. It takes a lot of work to reach the point where you realize OpenAPI isn’t just about documentation, a journey that most API developers end up not taking. Arnaud understands that OpenAPI isn’t just about API documentation, but is the fundamental underpinning of API design for any platform—something that will help define every other stop along your API lifecycle. The Design of Web APIs is the first API design book I have seen that merges API design and OpenAPI together in such a thoughtful and pragmatic way, which is sure to help many developers along in their API journey.

Spend the time to understand what Arnaud is sharing with you here. This isn’t a skimming book. This isn’t a one-read book. This is a handbook. This is your guide to taking the design of your APIs to the next level. It brings that loose bucket of API concepts you are familiar with and provides you with the blueprints to build the Millennium Falcon or even the Death Star (if you so choose) from your bucket of API Lego building blocks. I recommend reading this book, then putting it down for a month. Then get to work building an API and moving it from design to actually being deployed and publicly available—sharing it with a handful of developers. Then while you wait for feedback, sit down and read the book again. You will begin to understand the depth of what you hold in your hands and the value of the knowledge Arnaud is sharing with you. Then repeat this process until you are satisfied with your ability to design not a perfect API, but exactly the API you need to reach the consumers you are looking to make an impact upon.

—Kin Lane, The API Evangelist


For most of my career, I have worked on connecting software bricks together using various software interface technologies, from simple files and databases to remote software interfaces based on RPC, Corba, Java RMI, SOAP web services, and web APIs. Throughout these years, I have been fortunate to work on motley distributed systems, mixing very old mainframe technology with state-of-the art cloud systems and everything in between. I also have been fortunate to work on both sides of software interfaces in various contexts. I worked on IVR (Interactive Voice Response), websites, and mobile applications built on top of huge service-oriented architecture systems. I’ve built both private and public web services and web APIs for frontend and backend applications. During all these years, I complained a lot about the terrible software interfaces, and I fell into many traps and created terrible software interfaces too.

As years passed, and technology evolved from RPC to SOAP web services and web APIs, connecting software together became more and more simple from a technical point of view. But whatever the technology used, I have learned that a software interface is far more than technical plumbing or a by-product of a software project.

After attending my first API conferences in 2014, “API Days” in Paris, I realized that many other people were struggling with APIs just like me. That is why in 2015 I started my API Handyman blog and also started to participate in API conferences. I wanted to share my experiences with others and help them to avoid falling in the same traps I had fallen into. Writing and speaking about web APIs not only allowed me to help others, it also allowed me to learn even more about them.

After two years of blogging and speaking at conferences, the idea of writing a book came. I wanted to write a book for my old self who fell into so many traps. As luck would have it, Manning Publications was looking for someone willing to write a book about the OpenAPI Specification, an API description format (we’ll talk about it in chapter 4, by the way). I took a chance and proposed my Design of Everyday APIs book, and it was accepted. This title was inspired by Don Norman’s Design of Everyday Things (MIT Press, 1998), which is a book about design (you definitely should read it). My idea was later replaced by the more straightforward The Design of Web APIs. I have to admit that I am more comfortable with this title; I don’t feel I’m borrowing from the fame of Don Norman anymore.

In the beginning, the book’s content included the design of everyday things + API + REST vs. gRPC vs. GraphQL. It would have been quite indigestible, but I wanted to make a book whose principles could be used for any type of API. Month after month, the content was refined and enhanced to what is now The Design of Web APIs. I chose to focus on REST APIs and use those as a support example for you to learn web/remote API design principles, which would go beyond merely designing APIs. I think my old self would have been quite happy to read this book; I hope you like it too!” (DWAPI)


Fair Use Sources:

JavaScript Software Engineering

Document Object Model (DOM)

See also: JavaScript, JavaScript Bibliography and Bibliography of JavaScript Libraries and Web Frameworks

First publishedOctober 1, 1998; 22 years ago
Latest versionDOM4[1]
November 19, 2015; 5 years ago
OrganizationWorld Wide Web ConsortiumWHATWG
Base standardsWHATWG DOM Living Standard

“The Document Object Model (DOM) is a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree. Each branch of the tree ends in a node, and each node contains objects. DOM methods allow programmatic access to the tree; with them one can change the structure, style or content of a document. Nodes can have event handlers attached to them. Once an event is triggered, the event handlers get executed.[2]

The principal standardization of the DOM was handled by the World Wide Web Consortium (W3C), which last developed a recommendation in 2004. WHATWG took over the development of the standard, publishing it as a living document. The W3C now publishes stable snapshots of the WHATWG standard.” (WP)

See also


  1. ^ All versioning refers to W3C DOM only.
  2. ^ “Document Object Model (DOM)” W3C. Retrieved 2012-01-12. The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents.
  3. ^ “DOM Standard”. Retrieved 23 September 2016.
  4. ^ “W3C Document Object Model”. Retrieved 23 September 2016.
  5. ^ (, Philippe Le Hegaret. “New Charter for the HTML Working Group from Philippe Le Hegaret on 2013-09-30 ( from September 2013)”. Retrieved 23 September2016.
  6. ^ “PubStatus – WEBAPPS”. Retrieved 23 September 2016.
  7. ^ “W3C DOM4”. Retrieved 8 January 2021.
  8. ^ “A Survey of Techniques for Improving Efficiency of Mobile Web Browsing“, Concurrency and Computation, 2018
  9. ^ “JavaScript HTML DOM”. Retrieved 23 September 2016.
  10. ^ Kogent Solutions Inc. (2008). Ajax Black Book, New Edition (With Cd). Dreamtech Press. p. 40. ISBN 978-8177228380.
  11. ^ “XML for <SCRIPT> Cross Platform XML Parser in JavaScript”. Retrieved 23 September 2016.
  12. ^ “The modern DOM API for PHP 7 projects”.

General references

External links

Wikimedia Commons has media related to document object models.



Fair Use Sources: