Added chapter 2
All checks were successful
Build and Deploy MkDocs / deploy (push) Successful in 11s

This commit is contained in:
John Gatward
2026-03-06 12:10:18 +00:00
parent c86b40baf6
commit b2a1f705a9
3 changed files with 45 additions and 0 deletions

View File

@@ -78,3 +78,23 @@ What is the purpose of building an API in the first place?
- We could think of simplicity as the number of endpoints.
- However an API that relies on a single `ExecuteAction()` method just shifts complexity from one place to another.
- APIs should aim to expose the functionality users want in the most straightforward way possible, making the API as simple as possible, but no simpler.
- **Make the common case fast**
- Whenever you add something that might complicate the API for the benefit of an advanced user, it is best to keep this complexity hidden from a basic user.
- This keeps the more frequent scenarios simple and easy whilst enabling advanced features for those who want them.
- e.g. Image a translation API. `GET /translate?lang=en`, allowing the user to add a specific language model as a mandatory field is complex for the average user and will slow down basic scenarios.
### Predictable
APIs that rely on repeated patterns applied to both the API surface definition and the behaviour.
Users very rarely learn an entire API, they learn the parts they need to and make assumptions when they need to make additions. e.g. if a query parameter is called text in one endpoint, it should not be called string or query in another.
APIs that rely on **repeated**, **predictable** patterns are easier and faster to learn; and therefore better.
### Summary
- Interfaces are contracts that define how two systems should interact with one another.
- APIs are a special type of interface
- Web APIs are again a special type of API that is exposed over a network.
- **Resource-oriented** APIs are a way of designing APIs to reduce complexity by relying on a standard set of actions, called *methods*, across a limited set of resources.
- Good APIs are generally: *operational*, *expressive*, *simple* and *predictable*.

View File

@@ -0,0 +1,24 @@
# 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.
Page 20: 2.3.3 Overview