Resource-based design thinking in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this REST API response simulation?

Consider a REST API endpoint that returns a JSON object representing a resource. What will be the output when the following Python code simulates a GET request to this resource?

Rest API

import json

def get_resource():
    resource = {
        "id": 101,
        "type": "book",
        "attributes": {
            "title": "Learn REST",
            "author": "Jane Doe"
        },
        "links": {
            "self": "/api/books/101"
        }
    }
    return json.dumps(resource)

print(get_resource())

A {"resource_id": 101, "resource_type": "book", "details": {"title": "Learn REST", "author": "Jane Doe"}}

B {"id": 101, "type": "book", "title": "Learn REST", "author": "Jane Doe", "self": "/api/books/101"}

C {"id": 101, "type": "book", "attributes": {"title": "Learn REST", "author": "Jane Doe"}, "links": {"self": "/api/books/101"}}

D [{"id": 101, "type": "book", "attributes": {"title": "Learn REST", "author": "Jane Doe"}}]

💡 Hint

Look carefully at how the JSON object is structured with nested dictionaries and keys.

The function returns a JSON string with keys 'id', 'type', 'attributes', and 'links' exactly as defined. Option C matches this structure exactly.

🧠 Conceptual

intermediate

Which HTTP method is best suited for updating a resource partially?

In resource-based design thinking for REST APIs, which HTTP method should be used to update only some fields of an existing resource without replacing the entire resource?

A PATCH

B DELETE

C PUT

D GET

💡 Hint

Think about the difference between replacing a resource and modifying parts of it.

PATCH is designed to partially update a resource, while PUT replaces the entire resource. GET retrieves, and DELETE removes the resource.

🔧 Debug

advanced

Identify the error in this REST API resource URL design

Which option shows an incorrect RESTful resource URL design for accessing a user's order?

A /users/123/orders/456/items

B /users/123/orders?id=456

C /users/123/orders/456

D /orders/456/users/123

💡 Hint

Consider the hierarchy and logical nesting of resources in RESTful URLs.

Option D places 'orders' before 'users', which breaks the logical parent-child relationship. Orders belong to users, so user ID should come first.

📝 Syntax

advanced

Which JSON response correctly represents a collection of resources?

Given a REST API returning multiple book resources, which JSON response is correctly formatted to represent a collection?

A }]}"B kooB" :"eltit" ,2 :"di"{ ,}"A kooB" :"eltit" ,1 :"di"{[ :"skoob"{

B {"books": [{"id": 1, "title": "Book A"}, {"id": 2, "title": "Book B"}]}

C [{"id": 1, "title": "Book A"}, {"id": 2, "title": "Book B"}]

D {"book": [{"id": 1, "title": "Book A"}, {"id": 2, "title": "Book B"}]}

💡 Hint

Look for proper JSON syntax with arrays and objects.

Option B correctly uses a key 'books' with an array of book objects. Option B is valid JSON but lacks a key to identify the collection. Options A and B have syntax errors.

🚀 Application

expert

What is the correct status code for a successful resource creation in REST API?

When a new resource is successfully created using a POST request, which HTTP status code should the server return?

A 201 Created

B 200 OK

C 204 No Content

D 202 Accepted

💡 Hint

Think about the standard code that indicates a new resource was made.

201 Created indicates that the request has succeeded and a new resource has been created as a result. 200 OK is generic success, 204 No Content means success with no body, and 202 Accepted means request accepted but not completed.

Practice

1. What is the main idea behind resource-based design thinking in REST APIs?

easy

A. Focusing only on database tables

B. Using only POST requests for all actions

C. Designing APIs without any structure

D. Organizing APIs around things like users or products

Solution

1. Step 1: Understand the concept of resource-based design

   Resource-based design means APIs are built around resources, which are things like users, products, or orders.

2. Step 2: Compare options to the concept

   Only Organizing APIs around things like users or products correctly describes organizing APIs around things (resources). Other options describe incorrect or unrelated ideas.

3. Final Answer:

   Organizing APIs around things like users or products -> Option D

4. Quick Check:

   Resource-based design = Organizing APIs around resources [OK]

Hint: Think of APIs as managing 'things' like users or products [OK]

Common Mistakes:

• Confusing resource-based design with database design
• Thinking all requests must be POST
• Ignoring the concept of resources

2. Which HTTP method is typically used to update an existing resource in a REST API?

easy

A. PUT

B. POST

C. GET

D. DELETE

Solution

1. Step 1: Recall HTTP methods and their common uses

   GET retrieves data, POST creates new data, PUT updates existing data, DELETE removes data.

2. Step 2: Identify the method for updating

   PUT is the standard method used to update an existing resource in REST APIs.

3. Final Answer:

   PUT -> Option A

4. Quick Check:

   Update resource = PUT [OK]

Hint: PUT means replace or update a resource fully [OK]

Common Mistakes:

• Using POST to update instead of create
• Confusing GET with update
• Using DELETE for updating

3. Given this REST API call: DELETE /products/123, what is the expected result?

medium

A. Retrieve product with ID 123

B. Create a new product with ID 123

C. Delete product with ID 123

D. Update product with ID 123

Solution

1. Step 1: Analyze the HTTP method and URL

   DELETE method means remove. The URL targets the product resource with ID 123.

2. Step 2: Determine the action

   DELETE /products/123 means delete the product with ID 123 from the system.

3. Final Answer:

   Delete product with ID 123 -> Option C

4. Quick Check:

   DELETE + resource ID = delete that resource [OK]

Hint: DELETE + resource ID means remove that resource [OK]

Common Mistakes:

• Thinking DELETE retrieves data
• Confusing DELETE with POST or PUT
• Ignoring the resource ID in URL

4. You see this API request: POST /users/45. What is wrong with this request in resource-based design?

medium

A. The URL should be /users without ID for creating

B. POST cannot be used to create resources

C. The HTTP method should be PUT

D. POST must include a resource ID in the URL

Solution

1. Step 1: Understand POST usage in REST

   POST is used to create new resources. The URL should point to the collection, not a specific resource ID.

2. Step 2: Analyze the request URL

   Including an ID (like /users/45) with POST is incorrect because the server assigns IDs when creating new resources.

3. Final Answer:

   The URL should be /users without ID for creating -> Option A

4. Quick Check:

   POST to collection URL without ID = correct [OK]

Hint: POST creates; URL should be collection without ID [OK]

Common Mistakes:

• Using POST with resource ID in URL
• Thinking POST updates existing resource
• Confusing POST and PUT URLs

5. You want to design an API to manage orders and their items. Which URL and HTTP method combination best follows resource-based design to update the quantity of item 7 in order 42?

hard

A. POST /orders/42/items with item ID and quantity in body

B. PUT /orders/42/items/7 with updated quantity in body

C. DELETE /orders/42/items/7 to update quantity

D. GET /orders/42/items/7 with quantity in query

Solution

1. Step 1: Identify the resource and action

   The resource is the specific item (ID 7) inside order 42. Updating quantity means modifying this resource.

2. Step 2: Choose correct HTTP method and URL

   PUT is used to update existing resources. The URL should point to the specific item resource: /orders/42/items/7.

3. Final Answer:

   PUT /orders/42/items/7 with updated quantity in body -> Option B

4. Quick Check:

   Update nested resource = PUT to specific item URL [OK]

Hint: Use PUT on specific nested resource URL to update it [OK]

Common Mistakes:

• Using POST to update existing item
• Using DELETE to update data
• Using GET with query to change data