Why advanced patterns solve real problems in Rest API - See It in Action

Why Advanced Patterns Solve Real Problems

📖 Scenario: You are building a REST API for a bookstore. The API needs to handle different types of requests efficiently and cleanly. Using advanced design patterns helps organize your code, making it easier to maintain and extend as the bookstore grows.

🎯 Goal: Build a simple REST API simulation using advanced patterns like the Command pattern to handle different API actions. This will show how advanced patterns solve real problems by making the code modular and scalable.

📋 What You'll Learn

Create a dictionary called commands to map action names to functions

Define separate functions for list_books, add_book, and remove_book

Use a variable action to select which command to run

Use the command pattern to call the correct function based on action

Print the result of the command execution

💡 Why This Matters

🌍 Real World

Advanced patterns like the Command pattern help developers build APIs that are easy to update and add new features without breaking existing code.

💼 Career

Understanding and applying design patterns is a key skill for software developers working on scalable and maintainable backend systems.

1

DATA SETUP: Create initial book list

Create a list called books with these exact strings: '1984', 'Brave New World', 'Fahrenheit 451'.

Rest API

# Create the list of books
# Your code here

Hint

Use square brackets to create a list with the exact book titles.

2

CONFIGURATION: Define the action variable

Create a variable called action and set it to the string 'list'.

Rest API

books = ['1984', 'Brave New World', 'Fahrenheit 451']
# Set the action to 'list'
# Your code here

Hint

Assign the string 'list' to the variable action.

3

CORE LOGIC: Define command functions and map them

Define three functions: list_books() that returns the books list, add_book() that adds 'The Handmaid's Tale' to books and returns the updated list, and remove_book() that removes '1984' from books and returns the updated list. Then create a dictionary called commands mapping 'list' to list_books, 'add' to add_book, and 'remove' to remove_book.

Rest API

books = ['1984', 'Brave New World', 'Fahrenheit 451']
action = 'list'
# Define list_books, add_book, remove_book functions
# Create commands dictionary mapping actions to functions
# Your code here

Hint

Define each function exactly as described and map them in the commands dictionary.

4

OUTPUT: Execute the command and print the result

Use the action variable to get the correct function from commands and call it. Store the result in result. Then print result.

Rest API

books = ['1984', 'Brave New World', 'Fahrenheit 451']
action = 'list'

def list_books():
    return books

def add_book():
    books.append("The Handmaid's Tale")
    return books

def remove_book():
    books.remove('1984')
    return books

commands = {
    'list': list_books,
    'add': add_book,
    'remove': remove_book
}

# Call the function from commands using action and print the result
# Your code here

Hint

Use commands[action]() to call the function and print the returned list.

Practice

1. Why do advanced REST API patterns like pagination and consistent error handling matter in real-world applications?

easy

A. They slow down the API response time significantly.

B. They add unnecessary complexity to simple APIs.

C. They make APIs easier to use, maintain, and scale.

D. They are only useful for small projects.

Solution

1. Step 1: Understand the purpose of advanced patterns

   Advanced patterns like pagination and consistent error handling help organize API responses and interactions.

2. Step 2: Connect patterns to real-world benefits

   These patterns improve usability, maintainability, and scalability of APIs in practical applications.

3. Final Answer:

   They make APIs easier to use, maintain, and scale. -> Option C

4. Quick Check:

   Advanced patterns improve API usability = They make APIs easier to use, maintain, and scale. [OK]

Hint: Think about how patterns help users and developers [OK]

Common Mistakes:

• Assuming patterns only add complexity
• Believing patterns slow down APIs
• Thinking patterns are for small projects only

2. Which of the following is the correct way to indicate pagination in a REST API response header?

easy

A. X-Pagination-Page: 1

B. Pagination-Page: 1

C. Page-Number: 1

D. Page: 1

Solution

1. Step 1: Recall standard pagination header naming

   Common practice uses custom headers starting with 'X-' like 'X-Pagination-Page' to indicate page number.

2. Step 2: Compare options to standard naming

   Only 'X-Pagination-Page: 1' follows the common convention for pagination headers.

3. Final Answer:

   X-Pagination-Page: 1 -> Option A

4. Quick Check:

   Standard pagination header = X-Pagination-Page: 1 [OK]

Hint: Look for headers starting with 'X-' for custom metadata [OK]

Common Mistakes:

• Using generic header names without 'X-' prefix
• Confusing query parameters with headers
• Assuming 'Page' alone is a header

3. Given this REST API response snippet for pagination:

{
  "data": ["item1", "item2"],
  "page": 2,
  "per_page": 2,
  "total": 5
}

What is the total number of pages available?

medium

A. 2

B. 7

C. 5

D. 3

Solution

1. Step 1: Identify total items and items per page

   Total items = 5, items per page = 2.

2. Step 2: Calculate total pages needed

   Divide total by per_page: 5 / 2 = 2.5, round up to 3 pages.

3. Final Answer:

   3 -> Option D

4. Quick Check:

   5 items with 2 per page = 3 pages [OK]

Hint: Divide total items by per_page and round up [OK]

Common Mistakes:

• Using integer division without rounding up
• Confusing current page with total pages
• Ignoring total count and using data length

4. You have this error response from a REST API:

{
  "error": "Invalid ID",
  "code": 400
}

But your client expects error details under the key "message" instead of "error". How can you fix this to follow consistent error patterns?

medium

A. Change the API to return {"message": "Invalid ID", "code": 400}

B. Change the client to look for "error" key instead of "message"

C. Ignore the error and retry the request

D. Remove the "code" key from the response

Solution

1. Step 1: Identify the inconsistency

   The API returns error details under "error" but client expects "message" key.

2. Step 2: Fix the API response to match client expectation

   Change the API to use "message" key for error details to keep consistent error format.

3. Final Answer:

   Change the API to return {"message": "Invalid ID", "code": 400} -> Option A

4. Quick Check:

   Consistent error keys = Use "message" key in API response [OK]

Hint: Match error keys between API and client [OK]

Common Mistakes:

• Ignoring client expectations
• Retrying without fixing error format
• Removing important error code info

5. You want to design a REST API that returns a list of users with optional filtering by age and supports pagination. Which advanced pattern combination best solves this real problem?

hard

A. Use POST method to send filters in the body and ignore pagination.

B. Use query parameters for filters and pagination, and return consistent error messages.

C. Return all users in one response without filters or pagination.

D. Send filters as headers and paginate by splitting responses manually.

Solution

1. Step 1: Identify best practices for filtering and pagination

   Filters are commonly passed as query parameters; pagination also uses query parameters for page and size.

2. Step 2: Combine with consistent error handling

   Returning consistent error messages helps clients handle issues gracefully.

3. Final Answer:

   Use query parameters for filters and pagination, and return consistent error messages. -> Option B

4. Quick Check:

   Filters + pagination via query params + consistent errors = Use query parameters for filters and pagination, and return consistent error messages. [OK]

Hint: Use query params for filters and pagination [OK]

Common Mistakes:

• Ignoring pagination causing large responses
• Using POST instead of GET for filtering
• Sending filters in headers which is non-standard