Added chapter 2
All checks were successful
Build and Deploy MkDocs / deploy (push) Successful in 11s
All checks were successful
Build and Deploy MkDocs / deploy (push) Successful in 11s
This commit is contained in:
@@ -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*.
|
||||
|
||||
24
docs/books/api_design_patterns/part1/chapter2.md
Normal file
24
docs/books/api_design_patterns/part1/chapter2.md
Normal 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
|
||||
Reference in New Issue
Block a user