diff --git a/absolute-beginners/backend-beginner/api-design/_category_.json b/absolute-beginners/backend-beginner/api-design/_category_.json new file mode 100644 index 0000000..43e3a6a --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "API Design & REST", + "position": 8, + "link": { + "type": "generated-index", + "description": "Learn how to build the bridges that connect your server to the world. Master RESTful principles, HTTP methods, and status codes." + } +} \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/api-testing-tools.mdx b/absolute-beginners/backend-beginner/api-design/api-testing-tools.mdx new file mode 100644 index 0000000..8a57944 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/api-testing-tools.mdx @@ -0,0 +1,91 @@ +--- +sidebar_position: 8 +title: "API Testing Tools" +sidebar_label: "8. Testing Tools" +description: "Learn how to test and debug your API endpoints using Postman, Thunder Client, and cURL." +--- + +Youโ€™ve designed your endpoints, chosen your status codes, and secured them with JWT. Now, how do you actually "call" them? Since we don't have a frontend yet, we use **API Testing Tools**. + +These tools act as a "Universal Client" that can send any HTTP request to any server. + +## Top 3 Tools for Developers + + + + + ### Why we love it: + It is a lightweight extension that lives inside **VS Code**. You don't need to switch between apps! + + * **Best For:** Quick testing during coding. + * **Pros:** Fast, stays in your editor, supports "Collections" and "Environment Variables." + * **Installation:** Search for "Thunder Client" in the VS Code Extensions marketplace. + + + + + ### Why we love it: + The industry leader. If you work at a big tech company, they probably use Postman to document and share APIs. + + * **Best For:** Complex projects and team collaboration. + * **Pros:** Advanced automated testing, beautiful documentation, and cloud sync. + + + + + ### Why we love it: + A command-line tool that comes pre-installed on almost every OS (Linux, Mac, Windows). + + * **Best For:** Quick checks and automation scripts. + * **Example:** + ```bash + curl -X GET https://api.codeharborhub.com/v1/users + ``` + + + + +## Anatomy of an API Request + +When using these tools, you will need to configure four main parts: + +1. **Method:** Select GET, POST, PUT, or DELETE. +2. **URL (Endpoint):** Where is your server running? (e.g., `http://localhost:5000/api/users`). +3. **Headers:** This is where you put your **Content-Type** (usually `application/json`) and your **Authorization** tokens. +4. **Body:** For POST and PUT requests, this is where you paste your JSON data. + +## Understanding the Response + +Once you hit "Send," the tool will show you: + +```mermaid +graph TD + A[Hit Send] --> B{Server Process} + B --> C[Status Code: e.g., 200 OK] + B --> D[Response Time: e.g., 150ms] + B --> E[Response Body: The JSON Data] + +``` + +## Professional Workflow: Environment Variables + +Don't hardcode your URLs! Imagine you have 50 requests. If you change your port from `5000` to `8000`, you don't want to edit 50 requests manually. + +**Use Variables:** + +* Create a variable called `{{base_url}}`. +* Set it to `http://localhost:5000`. +* Your requests will look like: `{{base_url}}/users`. + +*Now, when you go to production, you just change the variable once!* + +## Summary Checklist + +* [x] I have installed **Thunder Client** or **Postman**. +* [x] I know how to set the HTTP Method and URL. +* [x] I can send a JSON body in a POST request. +* [x] I understand how to read the Status Code and Response Body. + +:::success ๐ŸŽ‰ Module Complete! +You have mastered the theory of **Relational Databases** and **API Design**. You are now officially ready to start writing real code! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/authentication.mdx b/absolute-beginners/backend-beginner/api-design/authentication.mdx new file mode 100644 index 0000000..3b76c25 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/authentication.mdx @@ -0,0 +1,87 @@ +--- +sidebar_position: 6 +title: "API Authentication" +sidebar_label: "6. Authentication" +description: "Learn how to secure your APIs using modern authentication methods like API Keys and JWT." +--- + +In the previous lessons, we built APIs that anyone could call. But in the real world, you don't want strangers deleting your data! **Authentication (AuthN)** is how the server verifies that a request is coming from a valid user. + +## ๐Ÿง Authentication vs. Authorization + +These two sound similar, but they are very different. At **CodeHarborHub**, we use the "Office Building" analogy: + +* **Authentication (AuthN):** Showing your ID card at the gate to enter the building. (*Who are you?*) +* **Authorization (AuthZ):** Your ID card only lets you into the 4th floor, not the CEO's office. (*What are you allowed to do?*) + +## Common Auth Methods + +Modern APIs usually use one of these three methods to keep things secure: + + + + + ### Simple & Fast + The server gives the client a long, secret string (the Key). The client sends this key in the header of every request. + * **Best For:** Public APIs (like Google Maps or Weather APIs). + * **Risk:** If someone steals your key, they can act as you. + + + + + ### The Industry Standard + **JSON Web Tokens** are like a digital "Boarding Pass." Once you login, the server gives you a signed token. You show this token for every future request. + * **Best For:** Modern Web and Mobile apps. + * **Feature:** It's **Stateless** (the server doesn't need to check the database every time). + + + + + ### Third-Party Login + This allows you to "Login with Google" or "Login with GitHub." + * **Best For:** User convenience and high security. + * **Benefit:** You don't have to manage passwords; Google does it for you! + + + + +## The Token-Based Workflow (JWT) + +This is the most common flow you will build as a Backend Developer: + +```mermaid +sequenceDiagram + participant C as Client (User) + participant S as Server (API) + participant DB as Database + + C->>S: 1. Login (Username + Password) + S->>DB: 2. Verify Credentials + DB-->>S: 3. Correct! + S->>S: 4. Generate JWT Token + S-->>C: 5. Send Token back + Note over C,S: Subsequent Requests + C->>S: 6. GET /profile (Header: Bearer ) + S->>S: 7. Verify Token Signature + S-->>C: 8. Here is your Private Data! + +``` + +## Best Practices for API Security + +1. **Always use HTTPS:** Never send passwords or tokens over `http`. They can be easily stolen. +2. **Use the Authorization Header:** Don't put tokens in the URL. Use the standard header: +`Authorization: Bearer ` +3. **Set Expiration:** Tokens should not last forever. If a token is stolen, it should expire in a few hours. +4. **Don't Store Secrets in Frontend:** Never hardcode your API keys in your React or HTML code. Use `.env` files. + +## Summary Checklist + +* [x] I understand that Authentication proves **identity**. +* [x] I know the difference between Authentication and Authorization. +* [x] I understand the JWT "Boarding Pass" workflow. +* [x] I know that sensitive data must always be sent over HTTPS. + +:::danger Security Warning +Never, ever commit your API keys or Secrets to **GitHub**! If you do, hackers can find them in seconds. Always use a `.gitignore` file to hide your environment variables. +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/http-methods-status.mdx b/absolute-beginners/backend-beginner/api-design/http-methods-status.mdx new file mode 100644 index 0000000..f603c36 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/http-methods-status.mdx @@ -0,0 +1,74 @@ +--- +sidebar_position: 3 +title: "HTTP Methods & Status Codes" +sidebar_label: "3. Methods & Status" +description: "Learn the vocabulary of the webโ€”how to tell the server what to do and how to understand its response." +--- + +When you send a request to a REST API, you are essentially sending a message. To make sure the server understands you, you must use specific **Methods**. Once the server processes your request, it replies with a **Status Code**. + +## HTTP Methods (The "Verbs") + +Every request starts with a method that defines the **intent** of the action. + + + + + ### Purpose: Retrieve Data + Used when you want to "fetch" information. It is **Read-Only**. + * **Analogy:** Browsing a menu at a cafe. + * **Example:** `GET /users` (Get all users). + + + + + ### Purpose: Create Data + Used to send new data to the server to create a resource. + * **Analogy:** Placing a new order at the counter. + * **Example:** `POST /users` (Create a new account). + + + + + ### Purpose: Update Data + * **PUT:** Replaces the entire resource. + * **PATCH:** Updates only specific parts (like just the email). + * **Analogy:** Changing your mobile number on an existing account. + + + + + ### Purpose: Remove Data + Used to delete a specific resource. + * **Analogy:** Canceling your subscription. + * **Example:** `DELETE /users/1` (Delete user with ID 1). + + + + +## HTTP Status Codes (The Feedback) + +After you send a request, the server sends back a 3-digit number. This tells the client exactly what happened. + +| Range | Category | "Desi" Meaning | Typical Examples | +| :--- | :--- | :--- | :--- | +| **2xx** | **Success** | "Sab sahi hai!" (All Good) | **200 OK**, **201 Created** | +| **3xx** | **Redirection** | "Rasta badal lo." (Go elsewhere) | **301 Moved Permanently** | +| **4xx** | **Client Error** | "Tumhari galti hai." (Your fault) | **400 Bad Request**, **404 Not Found** | +| **5xx** | **Server Error** | "Meri galti hai." (My fault) | **500 Internal Server Error** | + +## Understanding the "Big Three" Codes + +1. **200 OK:** The request was successful, and here is your data! +2. **404 Not Found:** The URL you requested doesn't exist. (The "classic" internet error). +3. **500 Internal Server Error:** Your code crashed on the server. The client did nothing wrong, but the backend failed. + +## Summary Checklist +* [x] I know that **GET** is for reading and **POST** is for creating. +* [x] I understand the difference between **PUT** (Full update) and **PATCH** (Partial). +* [x] I can identify that **4xx** codes mean the issue is on the user's side. +* [x] I know that **201** is the standard code for a successful "Create" action. + +:::warning Common Beginner Mistake +Never use **GET** to send sensitive data like passwords! Data in a GET request is visible in the URL. Always use **POST** with a "Body" for secure information. +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/json-apis.mdx b/absolute-beginners/backend-beginner/api-design/json-apis.mdx new file mode 100644 index 0000000..5e505a5 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/json-apis.mdx @@ -0,0 +1,105 @@ +--- +sidebar_position: 5 +title: "JSON & API Communication" +sidebar_label: "5. JSON APIs" +description: "Learn about JSON, the universal data format for modern API communication." +--- + +When a Waiter (the API) brings your order from the Kitchen (the Server), the food is served on a **Plate**. In the digital world, **JSON** is that plate. + +**JSON** stands for **JavaScript Object Notation**. It is a lightweight, text-based format that is easy for humans to read and even easier for machines to parse. + +## ๐Ÿง Why JSON? + +Before JSON, the world used **XML**, which was very bulky and hard to read. JSON won the "format war" because: +1. **Lightweight:** It uses very few characters, making it fast to send over the internet. +2. **Language Independent:** Even though it has "JavaScript" in the name, almost every language (Python, Java, PHP, C#) can read it. +3. **Key-Value Pairs:** It organizes data exactly like a dictionary or a map. + +## The Structure of a JSON Object + +A JSON object is wrapped in curly braces `{}` and contains data in `key: value` pairs. + +```json +{ + "id": 101, + "name": "Ajay Dhangar", + "isMentor": true, + "skills": ["React", "Node.js", "SQL"], + "address": { + "city": "Mandsaur", + "state": "MP" + } +} +``` + +### Supported Data Types + + + +Text wrapped in double quotes: `"Hello CodeHarborHub"` + + +Integers or decimals: `25` or `99.99` + + +Ordered lists inside brackets: `["JavaScript", "HTML"]` + + +Nested data inside braces: `{"key": "value"}` + + + +## Sending and Receiving JSON + +When you build a backend at **CodeHarborHub**, you will deal with JSON in two ways: + +### 1. The Request Body + +When a user registers, they send their data to your server as a JSON string. + +```http +POST /users +Content-Type: application/json + +{ + "username": "coder_ajay", + "password": "securepassword123" +} +``` + +### 2. The Response + +Your server processes the logic and sends back a JSON response. + +```json +{ + "status": "success", + "message": "User created successfully", + "userId": 502 +} +``` + +## Tools for JSON + +### 1. JSON Formatter + +Raw JSON can sometimes look like a giant "wall of text." Use a browser extension like **JSON Viewer** to make it look beautiful and organized. + +### 2. JSON.stringify() vs JSON.parse() + +If you are using JavaScript: + +* **`JSON.stringify(obj)`**: Converts a JS object into a JSON string (to send to a server). +* **`JSON.parse(str)`**: Converts a JSON string into a JS object (to use in your code). + +## Summary Checklist + +* [x] I understand that JSON is a text format for storing and transporting data. +* [x] I know that JSON uses Key-Value pairs. +* [x] I can identify different data types like Strings, Numbers, and Arrays in JSON. +* [x] I understand that `Content-Type: application/json` is required in the header. + +:::tip Pro-Tip +Always validate your JSON! A single missing comma `,` or a missing double quote `"` will cause your entire API request to fail. Use a tool like **JSONLint** to check your work. +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/jwt.mdx b/absolute-beginners/backend-beginner/api-design/jwt.mdx new file mode 100644 index 0000000..45da074 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/jwt.mdx @@ -0,0 +1,90 @@ +--- +sidebar_position: 7 +title: "JSON Web Tokens (JWT)" +sidebar_label: "7. JWT Deep Dive" +description: "Understand the structure, security, and implementation of JSON Web Tokens in modern APIs." +--- + +In traditional web apps, the server had to "remember" every logged-in user (Session). But in modern, scalable backends, we use **JWT**. It is **stateless**, meaning the server doesn't need to keep a list of active users in its memory. + +## The Structure of a JWT + +A JWT looks like a long string of random characters, but it is actually made of three parts separated by dots (`.`): + +### 1. Header (The Type) +Contains information about the type of token and the hashing algorithm used (like HS256). + +```json +{ + "alg": "HS256", + "typ": "JWT" +} +``` + +### 2. Payload (The Data) + +This is the heart of the token. It contains the user's info (claims). **Warning:** This part is only encoded, not encrypted. Never put passwords here! + +```json +{ + "userId": "12345", + "name": "Ajay Dhangar", + "admin": true +} +``` + +### 3. Signature (The Security) + +The server takes the encoded Header, the encoded Payload, and a **Secret Key** known only to the server, and mixes them together. This ensures that if a hacker changes the `userId`, the signature will no longer match! + +## How the "Handshake" Works + +```mermaid +sequenceDiagram + participant U as User (Frontend) + participant S as Server (Backend) + + U->>S: 1. Login with Credentials + Note right of S: Server validates password + S->>S: 2. Create JWT with Secret Key + S-->>U: 3. Send JWT back to Browser + Note left of U: Browser stores JWT in LocalStorage/Cookie + U->>S: 4. Request Private Data (Sends JWT in Header) + S->>S: 5. Verify Signature with Secret Key + S-->>U: 6. Success! Data Sent. + +``` + +## Pros vs. Cons + +| Feature | Advantage | Disadvantage | +| --- | --- | --- | +| **Storage** | No server database needed for sessions. | Tokens can get large if you put too much data. | +| **Scalability** | Perfect for microservices and multiple servers. | **Impossible to "Log Out"** instantly (unless you use a blacklist). | +| **Security** | Highly secure against tampering. | If the Secret Key is leaked, your entire app is hacked. | + +## Implementation Tips + + + +Don't store JWTs in `localStorage` if you are worried about XSS attacks. The most secure way is to use an **HttpOnly Cookie**. + + +Always set an `exp` (expiration) claim. A token should usually last between 15 minutes and a few hours. + + +Keep your secret key in an `.env` file. +`JWT_SECRET=my_ultra_secure_random_string_123` + + + +## Summary Checklist + +* [x] I know that JWT has 3 parts: Header, Payload, and Signature. +* [x] I understand that the **Signature** prevents data tampering. +* [x] I know that anyone can read the **Payload**, so I won't put passwords in it. +* [x] I understand that JWTs make my backend **Stateless**. + +:::info Pro-Tip +You can debug and inspect any JWT at **[jwt.io](https://jwt.io)**. Try pasting a token there to see the header and payload instantly! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/rest-architecture.mdx b/absolute-beginners/backend-beginner/api-design/rest-architecture.mdx new file mode 100644 index 0000000..24a89f4 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/rest-architecture.mdx @@ -0,0 +1,76 @@ +--- +sidebar_position: 2 +title: "REST Architecture" +sidebar_label: "2. REST Principles" +description: "Understand the architectural constraints and principles that define a RESTful API." +--- + +**REST** stands for **Representational State Transfer**. It is not a programming language or a tool; it is an **architectural style**. + +Think of REST as the "Traffic Rules" for the internet. If everyone follows the same rules, communication between different systems (like a Mobile App and a Java Server) becomes seamless. + +## The 5 Core Principles of REST + +To be called a **RESTful API**, a system must follow these specific constraints: + + + + + ### No Memory + The server does **not** store any info about your previous requests. Every single request must contain all the information (like a Token or ID) needed to understand it. + + * **Analogy:** It's like a vending machine. It doesn't care if you bought a soda 5 minutes ago; you must put in the money and press the button every single time. + + + + + ### Separation of Concerns + The Frontend (Client) and Backend (Server) are independent. + + * You can completely redesign your Android app without ever touching your database code. As long as the API "Contract" stays the same, everything works! + + + + + ### Consistency + + Every resource (User, Post, Product) must have a unique URL. You should always use standard HTTP methods (GET, POST, etc.) to interact with them. + + * **Standard:** `GET /users/1` should always return user data, no matter which company built the API. + + + + +## The REST Communication Flow + +In a RESTful system, the communication is always initiated by the **Client**. The server just waits, listens, and responds. + +```mermaid +graph TD + Client[๐Ÿ“ฑ Client App] -- "HTTP Request (Method + URL)" --> API{๐ŸŒ REST API} + API -- "Process Request" --> DB[(๐Ÿ—„๏ธ Database)] + DB -- "Return Data" --> API + API -- "HTTP Response (JSON + Status Code)" --> Client + +``` + +## Resources: The Heart of REST + +In REST, everything is a **Resource**. A resource is any piece of data that the API can provide. + +* **Collections:** A list of items (e.g., `/products`) +* **Individual Items:** One specific item (e.g., `/products/101`) + +### How we identify them: + +We use **URIs** (Uniform Resource Identifiers). A good RESTful URI should use **nouns**, not verbs. + +* **Bad (Action-based):** `https://api.com/getNewOrders` +* **Good (Resource-based):** `https://api.com/orders` + +## Summary Checklist + +* [x] I understand that REST is an architectural style, not a language. +* [x] I know that **Statelessness** means every request is independent. +* [x] I understand that Client and Server are separate entities. +* [x] I recognize that resources should be named with **Nouns**. \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/rest-best-practices.mdx b/absolute-beginners/backend-beginner/api-design/rest-best-practices.mdx new file mode 100644 index 0000000..041de8d --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/rest-best-practices.mdx @@ -0,0 +1,91 @@ +--- +sidebar_position: 4 +title: "REST Best Practices" +sidebar_label: "4. Best Practices" +description: "Learn the industry-standard naming conventions and structural rules for building professional APIs." +--- + +Building an API is easy, but building a **good** API is an art. At **CodeHarborHub**, we want our developers to follow industry standards so that their code is "Production Ready" and easy for teammates to use. + +## Rule 1: Use Nouns, Not Verbs + +In REST, the URL should represent **What** the resource is, not **What you are doing** to it. The "doing" part is already handled by the HTTP Method (GET, POST, etc.). + +| Bad (Verb-based) | Good (Noun-based) | +| :--- | :--- | +| `GET /getAllUsers` | `GET /users` | +| `POST /createNewUser` | `POST /users` | +| `POST /updateUser/1` | `PATCH /users/1` | +| `DELETE /removeUser/1` | `DELETE /users/1` | + +## Rule 2: Use Plurals + +Consistency is key. It is a standard practice to use plural nouns for all endpoints, even if you are only interacting with a single item. + +* `/user/1` +* `/users/1` + +## Rule 3: Logical Hierarchies (Nesting) + +If a resource belongs to another resource, reflect that in the URL. This makes the relationship crystal clear, mimicking how you designed your SQL database tables. + +**Scenario:** You want to get all the orders placed by a specific user. + +```text +GET /users/101/orders +``` + +*This reads as: "Inside Users, find user 101, and give me their Orders."* + +## Rule 4: Filtering, Sorting, and Searching + +Don't create new URLs for searching. Use **Query Parameters** (the part after the `?`). This keeps your API surface small and predictable. + + + + +```text +GET /users?role=admin +``` + +*(Returns only the users who are admins)* + + + + +```text +GET /users?sort=desc +``` + +*(Returns users sorted in descending order)* + + + + +```text +GET /users?search=aryan +``` + +*(Returns users whose name contains 'aryan')* + + + + +## Rule 5: Versioning Your API + +As your app grows, you might need to change how the API works. To avoid breaking the app for existing users, always version your API. + +* `https://api.codeharborhub.com/v1/users` +* `https://api.codeharborhub.com/v2/users` + +## Summary Checklist + +* [x] I use **Nouns** for endpoints and **HTTP Verbs** for actions. +* [x] I always use **Plural** nouns (e.g., `/products` instead of `/product`). +* [x] I use **Nesting** to show relationships between resources. +* [x] I use **Query Parameters** for filtering and sorting data. +* [x] I understand why `/v1/` is important for future-proofing my API. + +:::info Pro-Tip +A clean API is self-documenting. If a developer can look at your URL and guess what it does without reading your manual, you have succeeded! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/api-design/what-is-an-api.mdx b/absolute-beginners/backend-beginner/api-design/what-is-an-api.mdx new file mode 100644 index 0000000..af92c73 --- /dev/null +++ b/absolute-beginners/backend-beginner/api-design/what-is-an-api.mdx @@ -0,0 +1,77 @@ +--- +sidebar_position: 1 +title: "What is an API?" +sidebar_label: "1. Concept of API" +description: "Learn the fundamental concept of Application Programming Interfaces (APIs) using real-world analogies." +--- + +You hear the term **API** everywhere in tech. But what does it actually mean? **API** stands for **Application Programming Interface**. + +To understand this without the "tech-speak," let's look at a scenario every Indian knows well: **Ordering food at a restaurant.** + +## The Restaurant Analogy + +Imagine you are sitting at a table in a restaurant (the **Client**). You want to eat a *Masala Dosa* (the **Data/Resource**). + +1. **The Client (You):** You are sitting at the table with a menu. You know what you want, but you can't go into the kitchen yourself. +2. **The Server (The Kitchen):** This is where the chef prepares the food. It has all the ingredients and the stove. +3. **The API (The Waiter):** The waiter comes to your table. You give the waiter your order. The waiter goes to the kitchen, tells the chef, and then brings the Dosa back to your table. + +**Without the waiter (API), you wouldn't know how to talk to the kitchen, and the kitchen wouldn't know what you want!** + +## What is an API in Software? + +In the digital world, an API is a set of defined rules that allow one software application to talk to another. + +* **Your Frontend (React/Vue):** Is the Client. +* **Your Backend (Node.js/Python):** Is the Server. +* **The API:** Is the "Endpoint" (URL) that connects them. + +### Real-World Digital Examples + + + + When you search "Weather in Bhopal" on Google, Google doesn't own weather satellites. It uses an **API** to ask a Weather Station for the data and shows it to you. + + + When you buy something on an app and use **PhonePe** or **GPay**, that app uses a Payment Gateway **API** to talk to your bank securely. + + + "Login with Google" or "Login with GitHub" buttons use **APIs** to verify your identity without the website ever seeing your password. + + + +## How an API Request Works + +Every time an API is called, a 4-step cycle happens: + +```mermaid +sequenceDiagram + participant C as Client (App) + participant A as API (The Bridge) + participant S as Server (Database) + + C->>A: 1. Request (Give me User #101) + A->>S: 2. Process (Hey Server, find User #101) + S->>A: 3. Data (Here is User #101's info) + A->>C: 4. Response (Here is your data!) + +``` + +## Key API Terminology + +* **Endpoint:** The specific URL where the API can be accessed (e.g., `https://api.codeharborhub.com/v1/users`). +* **Request:** The "order" you send to the API. +* **Response:** The "result" the API gives back (usually in **JSON** format). +* **JSON:** The most common language APIs speak. It looks like a JavaScript object. + +## Summary Checklist + +* [x] I understand that an API is a messenger between a Client and a Server. +* [x] I can explain the Restaurant/Waiter analogy. +* [x] I know that APIs allow different systems to share data safely. +* [x] I understand that endpoints are the URLs we use to talk to an API. + +:::info Why do we need APIs? +Security! An API acts as a gatekeeper. It allows the server to share *only* the data you are allowed to see, without giving you full access to the entire database. +::: \ No newline at end of file