# Introduction to API Design Patterns

## What are API Design Patterns?

A **software design *pattern*** is a particular design that can be applied over and over to lots of similar software problems, with only minor adjustments. It is not a pre-built library but more of a *blueprint* for solving similarly structured problems.

- Most often, design patterns focus on specific components rather than entire systems.
    - e.g. If you want to add a logging system, you can use the **singleton design pattern**.
    - This pattern is not complete
    - However, it's well-defined and well-tested pattern to follow when you need to solve this small compartmentalised problem of always having a single instance of a class.

## Why are API Design Patterns Important?

- While having programmatic access to a system is very valuable, it's also much more fragile and brittle.
    - Changes to the interface can easily cause failures for those using the interface.
- We refer to this aspect as *flexibility*
    - Interfaces where users can easily accommodate changes are *flexible*
        - GUIs are flexible - moving a button
    - Interfaces where even small changes cause complete failures are *rigid*.
        - Backend APIs: changing a query parameter breaks old client code.
- Rigid interfaces make it much more difficult to iterate toward a great design.
    - We are often stuck with all design decisions, both good and bad.

**Pagination Pattern**: The pagination pattern is a way of retrieving a long list of items in smaller, more manageable chunks. The pattern relies on extra fields on both the request and response.

Moving from a non-paginated to paginated response pattern:

Q. What happens if we don't start with the pattern?

1. All previously written clients are expected all the data in one list - it has no way of getting subsequent pages.
2. Clients are left to think they have all the data - which can lead to incorrect conclusions.