Wiring Up POST Commands: A Deep Dive by Tim Corey

Introduction to POST Commands

Tim begins by revisiting the interface updates from the previous lesson, noting that the system currently only supports GET requests. He explains that this lesson focuses on enabling POST requests so that users can send data to a server, such as JSON output or form data.

He emphasizes that separating the UI code from library code is key. The UI should manage elements like dropdowns, HTML forms, and input fields, while the library handles HTTP request creation, content formatting, and sending data to the server.

Tim also notes that this project can serve as a portfolio example, but it’s important for developers to ensure their portfolio is uniquely theirs. He references his Dev Pass at timcorey.com as a way to deepen understanding of C# and HTTP request methods.

Understanding the Current Setup

In Visual Studio, Tim demonstrates the current project setup. The UI allows selecting a request method (GET or POST) and entering a URL. Currently, clicking “Go” executes only a GET request, displaying the response in a results window.

One minor issue he points out is that all text in the results window is highlighted after a GET request, which isn’t ideal for displaying information. Tim fixes this by setting focus on the tab element instead of the text box. This prevents automatic text selection and improves the user experience.

Reading the Dropdown and Determining the HTTP Action

To implement POST commands, Tim first explains how to read the dropdown selection to determine the HTTP request method. He creates a variable to store the parsed request method and uses TryParse to convert the dropdown string value into an HTTP action.

If the selected method is invalid, the system displays an error message (“Invalid HTTP verb”) and does not attempt the request. Once validated, the request method can be used to determine whether to perform a GET request, POST request, or other HTTP methods like DELETE or PATCH.

Preparing the Backend to Handle POST Requests

The next step is updating the library to handle POST requests. Tim explains that POST commands differ from GET requests because they usually require a request body to send data to the target resource. This data could be JSON, binary data, or form data.

Tim emphasizes separating UI responsibilities from library code. The UI passes the body content as a string, and the library converts it to the correct HTTP content type for the request. This design ensures that generic operations like formatting content are handled in the library, not in the UI.

Creating an Overload for POST Requests

Tim creates an overload for CallApiAsync that accepts three parameters:

1. URL – the address of the target resource

2. Action – the HTTP request method (GET, POST, etc.)

3. Content – the request body as a string

This allows developers to pass JSON output, form data, or other encoded data from the UI directly to the library. By handling POST requests this way, the same library can also support future HTTP methods, such as PUT, PATCH, or DELETE.

Converting String Content to HTTP Content

Tim shows how to convert the string content from the UI into StringContent, which inherits from HTTP content. He sets the encoding to UTF8 and the content type to application/json, which is suitable for sending structured data to a server.

This step ensures that the request body is properly formatted before sending. Tim highlights that this separation of concerns allows developers to use POST commands without worrying about HTTP headers, encoding, or content conversion in the UI.

Updating the Interface and Testing POST Requests

Once the library is ready, Tim updates the UI to call the new overloaded method. He tests POST requests using JSONPlaceholder, manually formatting the request body:

{
  "title": "This is my title",
  "body": "This is my body text",
  "userId": 3
}

Tim explains that a POST request sends this data to the target resource, and the response indicates success. Initially, an error occurs because the HTTP action enum does not include POST. Adding POST resolves this, allowing the system to send POST commands successfully.

Handling POST Requests in the Library

Tim demonstrates handling POST commands in the library using a switch statement on the HTTP request method. For GET, the system uses GetAsync; for POST, it uses PostAsync with the formatted request body.

Testing the POST command returns a response with an ID (101 in JSONPlaceholder), confirming that the request worked. Tim notes that while this test API does not store data in a database, it is useful for validating POST request functionality.

Key Takeaways and Future Work

Tim summarizes the lesson:

• The dropdown now supports GET and POST methods.

• The UI passes the request body to the library.

• The library converts the string into HTTP content and executes the correct HTTP request.

• POST commands return valid responses, which can be displayed in the results window.

He encourages learners to implement PUT, PATCH, and DELETE commands in future lessons, highlighting that the existing framework makes adding new HTTP methods straightforward.

Tim also advises avoiding over-engineering or adding unused code, which could result in disconnected functions or orphaned elements.

Conclusion

Tim Corey’s video provides a clear, practical approach to POST commands in a Postman Clone project. By separating UI responsibilities from library code, converting string data into HTTP content, and handling responses effectively, developers gain hands-on experience with HTTP request methods.

This lesson not only demonstrates sending data to a server but also lays the foundation for handling other HTTP methods, headers, and more complex requests, making it a strong practical example for learning HTTP interactions in C#.