Skip to main content
In this article, we review the changes introduced in the previous lesson and outline the necessary updates to our application. Due to recent modifications, certain API requests demonstrate outdated behavior. We will walk through these requests and explain the adjustments required for proper functionality.

Logging In and Retrieving Posts

First, we log in a user, update a variable, and retrieve all posts using our Postman Essentials application. The image below illustrates a login request using the POST method with form data for the username and password. The response includes an access token and token type.
The image shows the Postman application interface with a request to log in a user using a POST method. It includes form data with a username and password, and the response displays an access token and token type.
When retrieving posts, even though our application currently returns one post, the response does not include the new “owner_id” field. For example, the JSON output appears as follows:
Since the owner ID is a newly added column, our schema must be updated to include it. This field is crucial as it informs users about the creator of the post.

Updating the Posts Endpoint

Examine the code in the posts router, specifically the endpoint for retrieving all posts. The response model references schemas.Post:
The schema for returning posts is based on PostBase, which currently includes fields like “title”, “content”, and “published”. It also defines the “id” and “created_at” fields that are generated at the database level:
To include the owner information in the response, we add an “owner_id” field to the output schema. Note that we do not require the owner to supply this field, as it will be derived automatically from the authentication token:
After updating the schema, hitting the endpoint returns a response that now includes the “owner_id”:

Reviewing the Get Single Post Endpoint

The post.py file contains similar schema definitions for retrieving an individual post:
The same model is utilized when creating a post. For example, consider the create post endpoint:
Logs confirm the successful execution of these endpoints:
Since all endpoints (retrieving all posts, a single post, creating a post, and updating a post) use the same schema (schemas.Post), updating it once is sufficient.

Updating a Post

The update post endpoint is defined as follows:
After updating, retrieving a post (for example, with ID 4) returns the following JSON response:
This confirms that the “owner_id” is now properly included in the response.
All endpoints currently reference the updated schemas.Post to include owner information. This single change now propagates across various functionalities like retrieving a post, updating a post, and creating a post.

Handling Owner ID During Post Creation

An issue arises when creating a post. If a new post is submitted without an owner ID (since this field is not provided in the request body), the database generates an error due to the NOT NULL constraint on the “owner_id” column:
This error indicates that while “owner_id” is mandatory in the database, the current logic does not automatically assign it during post creation. We will address this mechanism in the next article.

Conclusion

By updating the schema to include the “owner_id” field, the response for retrieving posts now provides clearer information about the post creator. However, the process for automatically assigning the owner ID during post creation still requires implementation. Stay tuned for the upcoming article, where we will tackle this issue and refine the owner assignment process.

Watch Video