diff --git a/docs/books/api_design_patterns/part1/chapter1.md b/docs/books/api_design_patterns/part1/chapter1.md
index c25e96a..45ea28f 100644
--- a/docs/books/api_design_patterns/part1/chapter1.md
+++ b/docs/books/api_design_patterns/part1/chapter1.md
@@ -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*.
diff --git a/docs/books/api_design_patterns/part1/chapter2.md b/docs/books/api_design_patterns/part1/chapter2.md
new file mode 100644
index 0000000..81a1599
--- /dev/null
+++ b/docs/books/api_design_patterns/part1/chapter2.md
@@ -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
diff --git a/mkdocs.yml b/mkdocs.yml
index c82ebe3..1868e6a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -69,5 +69,6 @@ nav:
     - API Design Patterns:
       - Part 1. Introduction:
         - Chapter 1. Introduction to APIs: books/api_design_patterns/part1/chapter1.md
+        - Chapter 2. Introduction to API Design Patterns: books/api_design_patterns/part1/chapter2.md