Bird
Raised Fist0
Rest APIprogramming~20 mins

Statelessness requirement in Rest API - Practice Problems & Coding Challenges

Choose your learning style10 modes available
Challenge - 5 Problems
🎖️
REST API Statelessness Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
❓ Predict Output
intermediate
2:00remaining
What is the output of this REST API statelessness simulation?

Consider a simple REST API simulation where each request is independent. The server does not store any client session data. What will be the output of the following code simulating two requests?

Rest API
class Server:
    def __init__(self):
        self.data = {}

    def handle_request(self, request):
        # Each request includes all needed info
        if request.get('action') == 'store':
            key = request.get('key')
            value = request.get('value')
            # Store data only for this request
            return f"Stored {key}={value}"
        elif request.get('action') == 'retrieve':
            key = request.get('key')
            # No stored data from previous requests
            return f"Value for {key}: None"

server = Server()

# First request stores data
print(server.handle_request({'action': 'store', 'key': 'x', 'value': '10'}))
# Second request tries to retrieve data
print(server.handle_request({'action': 'retrieve', 'key': 'x'}))
AStored x=10\nValue for x: 10
BStored x=10\nValue for x: None
CValue for x: None\nStored x=10
DValue for x: 10\nStored x=10
Attempts:
2 left
💡 Hint

Remember that stateless means the server does not keep data between requests.

🧠 Conceptual
intermediate
1:30remaining
Which statement best describes statelessness in REST APIs?

Choose the statement that correctly explains the statelessness requirement in REST APIs.

AEach request from client to server must contain all information needed to understand and process the request.
BThe server must store session data to track client state between requests.
CClients should never send authentication information with requests.
DThe server maintains a continuous connection to remember client data.
Attempts:
2 left
💡 Hint

Think about how REST APIs handle client data across multiple requests.

🔧 Debug
advanced
2:30remaining
Why does this REST API server violate statelessness?

Examine the code below. Why does this server violate the statelessness requirement?

Rest API
class Server:
    def __init__(self):
        self.sessions = {}

    def handle_request(self, request):
        session_id = request.get('session_id')
        if session_id not in self.sessions:
            self.sessions[session_id] = {'count': 0}
        self.sessions[session_id]['count'] += 1
        return f"Request count: {self.sessions[session_id]['count']}"
AThe server stores session data in self.sessions, keeping client state between requests.
BThe server does not handle requests properly because it lacks a session_id.
CThe server returns the wrong count value due to a syntax error.
DThe server is stateless because it uses session_id in requests.
Attempts:
2 left
💡 Hint

Check if the server keeps any data between requests.

❓ Predict Output
advanced
1:30remaining
What error does this stateless REST API code produce?

What error will this code produce when handling a request missing required data?

Rest API
def handle_request(request):
    # Expect 'user_id' in request
    user_id = request['user_id']
    return f"User ID is {user_id}"

print(handle_request({'action': 'get_data'}))
ANo error, prints 'User ID is None'
BValueError: invalid user_id
CKeyError: 'user_id'
DTypeError: missing 1 required positional argument
Attempts:
2 left
💡 Hint

What happens if you try to access a dictionary key that does not exist?

🚀 Application
expert
3:00remaining
How many items are stored in the server after these stateless requests?

A REST API server is designed to be stateless. It receives three requests in order:

  1. {"action": "add", "item": "apple"}
  2. {"action": "add", "item": "banana"}
  3. {"action": "list"}

The server code is:

class Server:
    def __init__(self):
        pass

    def handle_request(self, request):
        if request['action'] == 'add':
            # Does not store items
            return f"Added {request['item']}"
        elif request['action'] == 'list':
            # Always returns empty list
            return []

server = Server()
print(server.handle_request({"action": "add", "item": "apple"}))
print(server.handle_request({"action": "add", "item": "banana"}))
print(server.handle_request({"action": "list"}))

How many items will the server list after these requests?

ACannot determine
B1
C2
D0
Attempts:
2 left
💡 Hint

Think about whether the server keeps any data between requests.

Practice

(1/5)
1. What does the statelessness requirement in REST APIs mean?
easy
A. Each request from client to server must contain all information needed to understand and process it.
B. The server must remember all previous requests from the client.
C. The server stores user session data between requests.
D. The client does not need to send any authentication information after the first request.

Solution

  1. Step 1: Understand statelessness in REST

    Statelessness means the server does not keep any client context between requests.
  2. Step 2: Identify what each request must contain

    Each request must have all data needed to process it, including authentication and parameters.
  3. Final Answer:

    Each request from client to server must contain all information needed to understand and process it. -> Option A
  4. Quick Check:

    Statelessness = All info in each request [OK]
Hint: Remember: server forgets past requests, all info sent every time [OK]
Common Mistakes:
  • Thinking server stores session data
  • Assuming client sends partial info only once
  • Confusing statelessness with authentication persistence
2. Which of the following HTTP request examples follows the statelessness principle?
easy
A. POST /login HTTP/1.1\nHost: example.com\nCookie: sessionid=abc123
B. GET /profile HTTP/1.1\nHost: example.com
C. GET /profile HTTP/1.1\nHost: example.com\nReferer: /home
D. GET /profile HTTP/1.1\nHost: example.com\nAuthorization: Bearer token123

Solution

  1. Step 1: Check if request contains all needed info

    GET /profile HTTP/1.1\nHost: example.com\nAuthorization: Bearer token123 includes Authorization header, so server can authenticate without stored session.
  2. Step 2: Compare with other options

    POST /login HTTP/1.1\nHost: example.com\nCookie: sessionid=abc123 relies on cookies, which imply server state. Options B and D lack explicit authentication info.
  3. Final Answer:

    GET request with Authorization header carrying token -> Option D
  4. Quick Check:

    Auth info in request = stateless [OK]
Hint: Look for Authorization header in request to confirm statelessness [OK]
Common Mistakes:
  • Assuming cookies mean statelessness
  • Ignoring missing auth info in requests
  • Confusing Referer header with authentication
3. Consider this REST API server behavior: It does not store any client session data. A client sends two requests:
1. GET /data?user=123&token=abc
2. GET /data?user=123
What will happen on the second request?
medium
A. The server rejects the request due to missing authentication token.
B. The server processes the request successfully using stored session data.
C. The server processes the request ignoring authentication.
D. The server crashes because of missing parameters.

Solution

  1. Step 1: Analyze statelessness and authentication

    Since server is stateless, it does not remember previous tokens; each request must include token.
  2. Step 2: Check second request parameters

    Second request lacks token parameter, so server cannot authenticate and must reject it.
  3. Final Answer:

    Server rejects request due to missing authentication token. -> Option A
  4. Quick Check:

    Missing token means reject request [OK]
Hint: Every request needs auth info; missing it causes rejection [OK]
Common Mistakes:
  • Assuming server remembers token from first request
  • Thinking server ignores missing token
  • Believing server crashes on missing params
4. A developer wrote this REST API code snippet to handle user requests:
def handle_request(request):
    if 'session_id' in server_memory:
        user = server_memory['session_id']
        return f"Hello, {user}!"
    else:
        return "Unauthorized"

What is the main problem related to statelessness here?
medium
A. The code does not check for authentication token in the request.
B. The code correctly implements statelessness by using server memory.
C. The code stores session data on the server, violating statelessness.
D. The code uses request parameters properly for authentication.

Solution

  1. Step 1: Identify server memory usage

    The code checks 'session_id' in server_memory, meaning it stores client state on server.
  2. Step 2: Compare with statelessness principle

    Statelessness forbids server from storing client session data between requests.
  3. Final Answer:

    Code stores session data on server, violating statelessness. -> Option C
  4. Quick Check:

    Server storing session = stateful, not stateless [OK]
Hint: Stateless means no server memory of client sessions [OK]
Common Mistakes:
  • Thinking server memory use is allowed
  • Ignoring missing token checks
  • Assuming code is stateless because it returns a string
5. You are designing a REST API for a shopping cart. To keep it stateless, which approach is best to track the user's cart items across requests?
hard
A. Store the cart items in a server-side session linked to the user ID.
B. Require the client to send the full cart data with each request.
C. Save the cart data in a database and keep session ID on server memory.
D. Use cookies to store cart items and rely on server to read them.

Solution

  1. Step 1: Understand statelessness in API design

    Statelessness means server does not keep client state; all info must come with each request.
  2. Step 2: Evaluate options for cart tracking

    Require the client to send the full cart data with each request. requires the client to send the full cart data with each request, fitting statelessness. Options A, B, and C rely on server or cookies storing state.
  3. Final Answer:

    Require client to send full cart data with each request. -> Option B
  4. Quick Check:

    Client sends all data = stateless API [OK]
Hint: Keep server stateless by sending all data from client every time [OK]
Common Mistakes:
  • Using server sessions to store cart
  • Assuming cookies make API stateless
  • Relying on server memory for user data
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard