adds helper notes to wave 1

- strong hints towards to_dict, from_dict, and validate_model
- weak hint towards create_model

Author: anselrognlie

ada-project-docs/wave_01.md

@@ -42,6 +42,7 @@ Tasks should contain these attributes. **The tests require the following columns
 
 - Pay attention to the exact shape of the expected JSON. Double-check nested data structures and the names of the keys for any misspellings.
   - That said, remember that dictionaries do not have an implied order. This is still true in JSON with objects. When you make Postman requests, the order of the key/value pairings within the response JSON object does not need to match the order specified in this document. (The term "object" in JSON is analogous to "dictionary" in Python.)
+  - Notice that the details for a Task in the response is shared across all the endpoints that return Task details. Rather than repeating the same literal `dict` structure in each response, we should create a helper method that returns the `dict` structure for a Task, and use it in each relevant endpoint. This will ensure that all our responses are consistent.
 - Use the tests in `tests/test_wave_01.py` to guide your implementation.
 - You may feel that there are missing tests and missing edge cases considered in this wave. This is intentional.
   - You have fulfilled wave 1 requirements if all of the wave 1 tests pass.
@@ -87,6 +88,10 @@ and get this response:
 
 so that I know I successfully created a Task that is saved in the database.
 
+Remember that the knowledge of how to initialize a new model instance from the request dictionary is often left to the model itself, as it allows the model to control which fields are required and how they are initialized. We could add a class method to the Task model that initializes a new instance from a dictionary, and use this method in the route. If all of our models have this method, we could create a route helper method that initializes a new model instance from a dictionary, and use it in this route and any other route that creates a new model instance.
+
+Further, notice that the data nested under the `"task"` key is a dictionary representation of the task that was created. Creating a model helper method to return this dictionary, which we can then use to help build this route response, will improve the consistency of our endpoints.
+
 #### Get Tasks: Getting Saved Tasks
 
 As a client, I want to be able to make a `GET` request to `/tasks` when there is at least one saved task and get this response:
@@ -110,6 +115,8 @@ As a client, I want to be able to make a `GET` request to `/tasks` when there is
 ]
 ```
 
+Notice that each data item in the list is a dictionary representation of a task. Creating a model helper method to return this dictionary, which we can then use to help build this route response, will improve the consistency of our endpoints.
+
 #### Get Tasks: No Saved Tasks
 
 As a client, I want to be able to make a `GET` request to `/tasks` when there are zero saved tasks and get this response:
@@ -137,6 +144,10 @@ As a client, I want to be able to make a `GET` request to `/tasks/1` when there
 }
 ```
 
+Notice that the data nested under the `"task"` key is a dictionary representation of the task that was retrieved. Creating a model helper method to return this dictionary, which we can then use to help build this route response, will improve the consistency of our endpoints.
+
+Further, we should remember that retrieving a model by its ID is a common operation. We should consider creating a route helper method that can retrieve a model by its ID, and use it in this route. This method could start out only working for Task models. But knowing that we'll be working with Goal models later on, it might be worth generalizing this method to work with any model.
+
 #### Update Task
 
 As a client, I want to be able to make a `PUT` request to `/tasks/1` when there is at least one saved task with this request body:
@@ -156,6 +167,8 @@ The response should have a mimetype of "application/json" to keep our API respon
 
 Note that the update endpoint does update the `completed_at` attribute. This will be updated with custom endpoints implemented in Wave 3.
 
+We should remember that retrieving a model by its ID is a common operation. We should consider creating a route helper method that can retrieve a model by its ID, and use it in this route. This method could start out only working for Task models. But knowing that we'll be working with Goal models later on, it might be worth generalizing this method to work with any model.
+
 #### Delete Task: Deleting a Task
 
 As a client, I want to be able to make a `DELETE` request to `/tasks/1` when there is at least one saved task and get this response:
@@ -164,6 +177,8 @@ As a client, I want to be able to make a `DELETE` request to `/tasks/1` when the
 
 The response should have a mimetype of "application/json" to keep our API response type consistent.
 
+We should remember that retrieving a model by its ID is a common operation. We should consider creating a route helper method that can retrieve a model by its ID, and use it in this route. This method could start out only working for Task models. But knowing that we'll be working with Goal models later on, it might be worth generalizing this method to work with any model.
+
 #### No Matching Task: Get, Update, and Delete
 
 As a client, if I make any of the following requests:
@@ -179,7 +194,8 @@ The response code should be `404`.
 You may choose the response body.
 
 Make sure to complete the tests for non-existing tasks to check that the correct response body is returned.
- 
+
+By using a helper method to retrieve a model by its ID, we could ensure that the response for a non-existing model is consistent across all these routes.
 
 #### Create a Task: Invalid Task With Missing Data