update nav

docs/Requests/01_functional_api.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Functional API"
+parent: "Requests"
+nav_order: 1
+---
+
 # Chapter 1: The Simplest Way - The Functional API
 
 Welcome to the world of `Requests`! If you need to get information from a website or interact with a web service using Python, `Requests` is your friendly helper.

docs/Requests/02_request___response_models.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Request & Response Models"
+parent: "Requests"
+nav_order: 2
+---
+
 # Chapter 2: What Happens When You Order? Request & Response Models
 
 In [Chapter 1: The Simplest Way - The Functional API](01_functional_api.md), we saw how easy it is to fetch a webpage or send data using simple functions like `requests.get()` and `requests.post()`. We also noticed that these functions return something called a `Response` object.

docs/Requests/03_session.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Session"
+parent: "Requests"
+nav_order: 3
+---
+
 # Chapter 3: Remembering Things - The Session Object
 
 In [Chapter 1](01_functional_api.md), we learned the easiest way to make web requests using functions like `requests.get()`. In [Chapter 2](02_request___response_models.md), we looked at the `Request` and `Response` objects that structure our communication with web servers.

docs/Requests/04_cookie_jar.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Cookie Jar"
+parent: "Requests"
+nav_order: 4
+---
+
 # Chapter 4: The Cookie Jar - Remembering Website Visits
 
 In [Chapter 3: Remembering Things - The Session Object](03_session.md), we saw how `Session` objects are super useful for making multiple requests to the same website. A big reason they work so well is that they automatically remember **cookies** sent by the server, just like your web browser does.

docs/Requests/05_authentication_handlers.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Authentication Handlers"
+parent: "Requests"
+nav_order: 5
+---
+
 # Chapter 5: Authentication Handlers - Showing Your ID Card
 
 In [Chapter 4: The Cookie Jar](04_cookie_jar.md), we learned how `requests` uses `Session` objects and cookie jars to automatically remember things like login cookies. This is great for websites that use cookies to manage sessions after you log in.

docs/Requests/06_exception_hierarchy.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Exception Hierarchy"
+parent: "Requests"
+nav_order: 6
+---
+
 # Chapter 6: When Things Go Wrong - The Exception Hierarchy
 
 In [Chapter 5: Authentication Handlers](05_authentication_handlers.md), we learned how to prove our identity to websites that require login or API keys. We assumed our requests would work if we provided the correct credentials.

docs/Requests/07_transport_adapters.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Transport Adapters"
+parent: "Requests"
+nav_order: 7
+---
+
 # Chapter 7: Transport Adapters - Custom Delivery Routes
 
 In the previous chapter, [Chapter 6: Exception Hierarchy](06_exception_hierarchy.md), we learned how `requests` signals problems like network errors or bad responses. Most of the time, we rely on the default way `requests` handles sending our requests and managing connections.

docs/Requests/08_hook_system.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Hook System"
+parent: "Requests"
+nav_order: 8
+---
+
 # Chapter 8: The Hook System - Setting Up Checkpoints
 
 In [Chapter 7: Transport Adapters](07_transport_adapters.md), we saw how to customize the low-level details of *how* requests are sent and connections are managed, like setting custom retry strategies. Transport Adapters give you control over the delivery mechanism itself.