Adding Slowdowns and Error Codes - Building a Sample API in C# Course

Tim Corey

16m 21s

When building and testing modern applications, particularly those with web front ends, developers often face the need to simulate real-world scenarios like API delays and unexpected error responses. To support this, Tim Corey presents a highly practical walkthrough in his course lesson titled "Adding Slowdowns and Error Codes - Building a Sample API in C#". In this video, Tim illustrates how to enrich a minimal C# API with artificial delays and custom error responses - invaluable tools for simulating less-than-ideal situations during testing.

In this article, we'll walk you through the concepts and implementations Tim demonstrates in the video.

Introduction to the Sample API and Its Purpose

Tim begins the lesson by reiterating the value of having a sample API when learning web development. Such an API gives you something concrete to test your front-end applications against.

By the end of the course, Tim aims to build a robust API that includes:

• Sample data
• Documentation
• Health checks
• Simulated slowdowns
• Simulated errors
• Deployment options via Docker and VPS

In this specific lesson, Tim focuses on simulating slowdowns and generating error codes for realistic API behavior under adverse conditions.

Adding Artificial Delays to API Endpoints

Tim starts by adding an optional delay parameter to specific API endpoints - particularly those dealing with course data. His goal is to simulate slow API responses for better front-end testing.

Implementation Details:

• The delay parameter is a nullable integer representing milliseconds.
• To handle this, Tim transitions the endpoint methods into asynchronous methods (async) that return Task<IResult> instead of just IResult.
• If a delay is provided and is within acceptable bounds (not exceeding 300,000 milliseconds or 5 minutes), the method invokes Task.Delay() to pause execution.

At 2:33, Tim emphasizes the importance of bounding the delay. He sets a cap at 5 minutes to prevent unreasonable wait times that could make the application unresponsive or appear broken.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

This addition ensures that developers can simulate delays up to five minutes, useful for testing timeouts and responsiveness in the client application.

Testing the Delay Mechanism

Tim runs a few tests using Postman (or a Postman clone) to verify the delay logic. For instance:

• A delay=5000 (5 seconds) causes the API to pause before returning results.
• A delay=500 results in a shorter pause.

He observes that the actual delay will always be slightly longer than the specified value due to processing overhead - an important real-world nuance. As Tim notes at 5:09, you're not timing the API down to the millisecond but rather simulating a threshold.

Expanding Delay Functionality to More Endpoints

Tim doesn't stop with just the "load all courses" endpoint. He wants consistency, so he implements the same delay capability in the "load course by ID" endpoint.

At 6:15, he hits a snag: a naming conflict due to the automatic addition of "Async" to the method name when converting to asynchronous. Tim adjusts both method names to align with the Async naming convention for clarity and consistency.

Testing confirms the implementation:

• Delays are respected.
• Nonexistent records return 404 as expected after the delay.
• Removing the delay or passing empty values behaves appropriately, with Tim noting a UI quirk in Postman rather than an issue with the API itself (8:00).

Adding Custom Error Responses

Next, Tim introduces a valuable tool for API testing: a dedicated endpoint that can simulate various HTTP error codes.

At 9:13, he explains that while some endpoints (like the one returning a course by ID) naturally return 404 for missing data, there's no built-in way to test for other error codes - unless explicitly simulated.

Tim builds a new endpoint at /error/{code} that:

• Accepts an integer HTTP status code.
• Returns the corresponding HTTP error response using a switch expression.

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

This covers both common client-side errors and any custom codes a developer might wish to test against.

At 12:03, he adds this new endpoint to the program via app.AddErrorEndpoints() and marks the error class as static.

Testing the Error Endpoint

Tim now tests the error endpoint by passing various status codes:

• 400 returns "Bad Request"
• 401 returns "Unauthorized"
• 404 returns "Not Found"
• 301 returns "Moved Permanently"
• 405 returns "Method Not Allowed"

This shows the flexibility of the endpoint - not just for error codes, but for any HTTP status code. At 13:04, Tim confirms this approach is ideal for testing how front-end apps handle different server responses.

While he considered naming it /httpcode, he sticks with /error for simplicity, as it's primarily used for simulating error conditions.

Summary of Functional Enhancements

Tim wraps up the video by summarizing the improvements made to the API:

• Slowdowns simulate real-world latency in API responses.
• Error simulation provides flexibility to test against virtually any HTTP response.
• These features make the sample API more robust and invaluable for realistic testing scenarios.

At 14:16, Tim stresses the importance of these tools for testing how your app behaves under different API states, such as delayed responses or various server errors.

What's Next: Dockerizing the API

Although not covered in detail in this video, Tim hints at the next step: Dockerizing the API. This allows developers to run the sample API locally in a self-contained Docker container, making it easier to deploy and share in different environments.

Final Thoughts

Tim closes the video by reiterating his commitment to building a comprehensive sample API that includes realistic features developers actually need to test against. These include:

• Delays
• Errors
• Health checks
• Future plans for authentication and advanced endpoints

The goal is simple but powerful - equip developers with a tool that mimics the quirks of real APIs, so their applications are robust, reliable, and user-friendly.

Conclusion

By the end of this lesson, viewers are equipped with a better understanding of how and why to introduce artificial delays and error responses in their APIs. Tim Corey's approach is methodical, practical, and directly tied to real-world application testing needs. If you're looking to enhance your API testing game, this lesson is an excellent resource to follow - and now you know exactly where to look.

Watch the full video lesson by Tim Corey for hands-on guidance.