Graceful degradation in Rest API - Step-by-Step Execution

Concept Flow - Graceful degradation

Client sends API request

↓

Server processes request

↓

Check: Is full feature available?

No→Use fallback response

↓

Send degraded response

↓

Send full response

↓

Client receives response

The server tries to provide full features; if not possible, it sends a simpler fallback response so the client still works.

Execution Sample

Rest API

GET /api/data
Server checks feature availability
If feature missing:
  return fallback data
Else:
  return full data

This simulates a REST API that returns full data if available, or fallback data if not.

Execution Table

Step	Action	Feature Available?	Response Sent	Client Outcome
1	Client sends request	N/A	N/A	Waiting for response
2	Server checks feature	Yes	Full data JSON	Receives full data, app works fully
3	Client sends request	N/A	N/A	Waiting for response
4	Server checks feature	No	Fallback data JSON	Receives fallback data, app works with limited features
5	End	N/A	N/A	Process complete

💡 Execution stops after sending response to client.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
feature_available	undefined	true	false	false
response_sent	none	full data JSON	fallback data JSON	fallback data JSON
client_state	waiting	received full data	received fallback data	received fallback data

Key Moments - 2 Insights

Why does the server send fallback data instead of an error when the feature is missing?

Because graceful degradation means the server still responds with simpler data so the client can continue working, as shown in execution_table row 4.

What happens on the client side when fallback data is received?

The client still works but with limited features, as shown in execution_table row 4 under Client Outcome.

Visual Quiz - 3 Questions

Look at the execution_table, what response does the server send when the feature is not available?

A Fallback data JSON

B Full data JSON

C Error message

D No response

💡 Hint

Check execution_table row 4 under Response Sent.

At which step does the client receive the full data response?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at execution_table row 2 under Client Outcome.

If the server always sends full data, how would the variable 'feature_available' change?

A It would always be false

B It would always be true

C It would alternate true and false

D It would be undefined

💡 Hint

See variable_tracker row for 'feature_available' after Step 2.

Concept Snapshot

Graceful degradation means the server sends full features if possible.
If not, it sends simpler fallback data.
This keeps the client working without errors.
Useful for APIs when some features fail or are unavailable.
Always check feature availability before responding.

Full Transcript

Graceful degradation in REST APIs means the server tries to send full feature data to the client. If the full feature is not available, the server sends fallback data instead of an error. This way, the client can still function with limited features. The flow starts with the client sending a request. The server checks if the full feature is available. If yes, it sends the full data. If no, it sends fallback data. The client receives the response and continues working accordingly. Variables like 'feature_available' track if the full feature is ready. The response sent depends on this variable. This approach avoids breaking the client when some features fail.

Practice

1. What is the main goal of graceful degradation in REST APIs?

easy

A. To keep the API working even if some parts fail

B. To stop the API immediately when an error occurs

C. To ignore all errors and continue without response

D. To make the API faster by skipping error checks

Solution

1. Step 1: Understand graceful degradation purpose

   Graceful degradation means the system still works even if some parts fail.

2. Step 2: Compare options with this meaning

   Only To keep the API working even if some parts fail matches this idea by keeping the API working despite failures.

3. Final Answer:

   To keep the API working even if some parts fail -> Option A

4. Quick Check:

   Graceful degradation = keep working despite failure [OK]

Hint: Graceful degradation means continue working despite errors [OK]

Common Mistakes:

• Thinking it stops the API on error
• Assuming errors are ignored without response
• Confusing with performance optimization

2. Which of the following is the correct way to handle errors for graceful degradation in a REST API response (in pseudocode)?

easy

A. ignore errors and return nothing

B. return data; if error then stop

C. try { return data } catch { return fallbackData }

D. throw error without handling

Solution

1. Step 1: Identify error handling syntax

   Graceful degradation uses try-catch to handle errors and provide fallback data.

2. Step 2: Match options to this pattern

   try { return data } catch { return fallbackData } shows try-catch with fallback, others either stop or ignore errors.

3. Final Answer:

   try { return data } catch { return fallbackData } -> Option C

4. Quick Check:

   Use try-catch with fallback for graceful degradation [OK]

Hint: Use try-catch to return fallback on error [OK]

Common Mistakes:

• Not catching errors properly
• Stopping API on first error
• Ignoring fallback responses

3. Consider this pseudocode for a REST API endpoint:

function getUserData() {
  try {
    return fetchUserFromDB();
  } catch (error) {
    return { name: "Guest", id: 0 };
  }
}

What will getUserData() return if the database fetch fails?

medium

A. An error message

B. Nothing, the function crashes

C. Null

D. A default user object with name 'Guest' and id 0

Solution

1. Step 1: Analyze try block behavior

   If fetchUserFromDB() works, it returns user data.

2. Step 2: Analyze catch block fallback

   If an error occurs, catch returns default user object with name 'Guest' and id 0.

3. Final Answer:

   A default user object with name 'Guest' and id 0 -> Option D

4. Quick Check:

   Error fallback returns default user object [OK]

Hint: Catch returns default object on failure [OK]

Common Mistakes:

• Assuming function crashes on error
• Expecting null instead of fallback object
• Thinking error message is returned

4. This REST API code snippet is meant to provide graceful degradation but has a bug:

function getData() {
  try {
    return fetchData();
  } catch (error) {
    fallbackData;
  }
}

What is the problem?

medium

A. The try block is missing

B. The fallback data is not returned in the catch block

C. The function does not catch errors

D. The function returns twice

Solution

1. Step 1: Check catch block code

   The catch block has fallbackData; but does not return it.

2. Step 2: Understand function return behavior

   Without return, the function returns undefined on error, breaking graceful degradation.

3. Final Answer:

   The fallback data is not returned in the catch block -> Option B

4. Quick Check:

   Catch must return fallback data for graceful degradation [OK]

Hint: Always return fallback data inside catch block [OK]

Common Mistakes:

• Forgetting to return fallback data
• Misplacing try-catch blocks
• Assuming catch auto-returns value

5. You have a REST API that fetches user profile and user posts separately. To apply graceful degradation, which approach is best?

hard

A. If fetching posts fails, return profile with empty posts list

B. If fetching posts fails, return error and no profile

C. Stop API if either profile or posts fail

D. Ignore profile and only return posts

Solution

1. Step 1: Understand graceful degradation in multi-part fetch

   It means returning partial data if one part fails, not stopping all.

2. Step 2: Evaluate options for partial fallback

   If fetching posts fails, return profile with empty posts list returns profile and empty posts if posts fail, matching graceful degradation.

3. Final Answer:

   If fetching posts fails, return profile with empty posts list -> Option A

4. Quick Check:

   Partial data returned on failure = graceful degradation [OK]

Hint: Return partial data with fallback for failed parts [OK]

Common Mistakes:

• Stopping API on any failure
• Returning no data if one part fails
• Ignoring fallback for partial data