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:
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