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.