Please work directly on the provided dev branch to make your changes. When you're ready to submit, please open a single pull request merging dev into main.
Read the README.md file to see the instructions on how to run your assessment.
On the dev branch, please add the following API routes:
A new API route for fetching blog posts by authors
A new API route for updating a blog post
A markdown file with answers to questions in Part 3
Please ensure that only a logged in User can use these new routes.
Part 1: Fetching Blog Posts
Implement a route for fetching blog posts by authorIds. The route should:
Fetch blog posts that have at least one of the authors specified in the authorIds parameter in the request. Note: a helper function for fetching blog posts by a single author have been provided for you to use: Post.get_posts_by_user_id.
Sort the blog posts based on the provided query parameters (outlined below) and remove any duplicate blog posts (try to be efficient when doing this)
Return the blog posts in the response
Your route should exactly match the following specification for the request and responses. Note that the data returned from the database may need to be modified to match the expected response format.
Request
Route: /api/posts
Method: GET
Query Parameters:
authorIds:
Type: String (required)
Description: A comma separated list of integer user IDs.
Default value: N/A
Example value: "1,5"
sortBy:
Type: String (optional)
Description:The field to sort the blog posts by. The only acceptable values for this parameter are: id, reads, likes, popularity.
Default value: "id"
Example value: “popularity”
direction:
Type: String (optional)
Description: The direction for sorting. The only acceptable values for this parameter are: asc, desc.
Default value: "asc"
Example value: "desc"
Success Response
If the request was formed correctly, a success response containing a JSON payload should be returned.
All the properties of Post should be returned in the response in the format specified below:
Your route implementation should include error handling. When designing your implementation, think about what edge cases you need to handle and what error messages would be helpful. An example of error handling is verifying the format of the query parameters and that the user is allowed to perform this action. Your error responses should match the provided response format below:
Response Status Code: Use REST best practices when determining which status code to use
Response Body (JSON):
{"error": "<error message>"}
Part 2: Updating a Blog Post
Implement a route for an author to update one of their blog posts. The route should:
Ensure only an author of a post can update the post
Update the blog post, if it exists, in the database
Return the updated blog post in the response
Your route should exactly match this specification for the request and responses:
Request
Route: /api/posts/<postId>, where postId is an integer
Method: PATCH
Request Body (JSON): The following JSON properties can be updated (all properties are optional - if they are excluded from the request, they will not be modified):
authorIds:
Type: Array (Integer)(optional)
Description: An array of author IDs.
Example value: [1,5]
tags:
Type: Array (String) (optional)
Description: An array of tags.
Example value: [“health”, “tech”]
text:
Type: String (optional)
Description: The blog post text.
Example value: “Some long blog post text here.”
The example below shows a request modifying all the available properties. Your route should follow the same format:
{"authorIds": [1,5],"tags": ["tech","health"],"text": "Some very short blog post text here."}
Success Response
If the request was formed correctly, a success response containing a JSON payload should be returned. All the properties of Post should be returned in the response, as well as the user IDs of its authors. This is what your response format should be:
Response Status Code: 200
Response Body (JSON):
{"post": {"id": 1, # number"authorIds": [1,5], # arrayofnumbers"likes": 960, # number"popularity": 0.13, # number"reads": 50361, # number"tags": ["health","tech"], # arrayofstrings"text": "Some very short blog post text here." # string}}
Error Response
Your route implementation should include error handling. When designing your implementation, think about what edge cases you need to handle and what error messages would be helpful.An example of error handling is verifying the format of the query parameters and that the user is allowed to perform this action. Your error responses should match the provided response format below:
Response Status Code: Use REST best practices when determining which status code to use
Response Body (JSON):
{"error": "<error message>"}
Part 3: Written Evaluation
Lastly, please provide a markdown file with the answers to the following questions below.
The product team has decided that we want to make a change to this application such that authors of a blog post can have different roles:
Authors can be owners, editors, or viewers of a blog post. For any blog post, there must always be at least one owner of the blog post. Only owners of a blog post can modify the authors' list to a blog post (adding more authors, changing their role).
Questions:
What database changes would be required to the starter code to allow for different roles for authors of a blog post? Imagine that we’d want to also be able to add custom roles and change the permission sets for certain roles on the fly without any code changes.
How would you have to change the PATCH route given your answer above to handle roles?
Considerations
Please format your answers so that they are easy to digest, and do not include any code in your pull request related to these questions above. We will be evaluating both the quality of your answer as well as the quality of your written explanation of that answer.
Please include a file in the root of the repo called roles-proposal.md that addresses these questions.
Creating a Pull Request
Once you have finished writing your document, open a terminal window and navigate to the root directory of your project. First, check to see if you have any uncommitted changes with the command git status. This will list any files that have been modified and are not yet committed.
Add all the files you have modified
git add .
Commit all your files
git commit -m "<message>" # where <message> is a short message describing your changes (e.g. “Solution to Part 1”)
To push your changes to GitHub, run the following:
git push .
Finally, open a browser and open a pull request from dev into main - a visual example of this is below. Do not merge the pull request.
Screen.Recording.2022-10-25.at.3.28.03.PM.mov
Return to your assessment page and click the "Ready to Submit" button to move onto the next part of this assessment!