LaunchCodeEducation · tpenn · Jan 1, 2024
diff --git a/content/web-api-rest/_index.md b/content/web-api-rest/_index.md
@@ -7,9 +7,9 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Sally Steuterman # to be set by the page reviewer
 reviewerGitHub: gildedgardenia # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Terri Penn # update any time edits are made after review
+lastEditorGitHub: tpenn # update any time edits are made after review
+lastMod: 2024-01-01T06:33:27-06:00 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 ## Learning Objectives
@@ -44,7 +44,7 @@ You should also have an understanding of the following:
 1. RESTful web services
 1. Representational state transfer
 1. JSON serialization
-1. JASON deserialization
+1. JSON deserialization
 1. resource
 1. resource entity
 1. resource collection

diff --git a/content/web-api-rest/exercises/_index.md b/content/web-api-rest/exercises/_index.md
@@ -7,16 +7,16 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Sally Steuterman # to be set by the page reviewer
 reviewerGitHub: gildedgardenia # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Terri Penn # update any time edits are made after review
+lastEditorGitHub: tpenn # update any time edits are made after review
+lastMod: 2024-01-01T07:15:35-06:00 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 We've created a basic API application [here](https://github.com/LaunchCodeEducation/events-api). Before we ask you to fork and clone this, let's first think conceptually about the kinds of requests a client application could make to this API.
 
 ## The API
 
-The api starts by only exposing a single resource, `Event`, and four endpoints for interacting with it.
+The API starts by only exposing a single resource, `Event`, and four endpoints for interacting with it.
 
 ### The Resource
 
@@ -55,7 +55,7 @@ An example of a real `Event` JSON response to a `GET` request would look like th
 }
 ```
 
-Notice how this JSON is just a representation of an instance of the `Event` model class. The data shape has been converted from a Java object representation to a JSON string representation so it can be transported over HTTP. Recall that we perform this 
+Notice how this JSON is just a representation of an instance of the `Event` model class. The data shape has been converted from a Java object representation to a JSON string representation, so it can be transported over HTTP. Recall that we perform this 
 conversion, or serialization, so that our API can output data in a portable format that is language-agnostic.
 
 ### The Endpoints
@@ -179,7 +179,7 @@ Some items to consider:
 
 #### Delete a Coding Event
 
-Deleting a `Event` resource is an operation on a single entity. Just like the endpoint for getting a single entity, this endpoint requires a `id` path variable. When a resource is deleted, a RESTful API should respond with a `204` status code. Similar to the `201` status, this code indicates a success with no response body or special headers. 
+Deleting a `Event` resource is an operation on a single entity. Just like the endpoint for getting a single entity, this endpoint requires an `id` path variable. When a resource is deleted, a RESTful API should respond with a `204` status code. Similar to the `201` status, this code indicates a success with no response body or special headers. 
 
 If you attempt to delete a resource that doesn't exist (with an incorrect `id`), then the endpoint will respond with an expected `404` status and message.
 

diff --git a/content/web-api-rest/next-steps/_index.md b/content/web-api-rest/next-steps/_index.md
@@ -7,12 +7,12 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Sally Steuterman # to be set by the page reviewer
 reviewerGitHub: gildedgardenia # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Terri Penn # update any time edits are made after review
+lastEditorGitHub: tpenn # update any time edits are made after review
+lastMod: 2024-01-01:T07:17:31-06:00# UPDATE ANY TIME CHANGES ARE MADE
 ---
 
-We have covered the fundamentals aspects of the RESTful mental model and practical usage. However, RESTful design is a deep topic that even extends beyond the web and use of HTTP!
+We have covered the fundamental aspects of the RESTful mental model and practical usage. However, RESTful design is a deep topic that even extends beyond the web and use of HTTP!
 
 If you want to learn more, the following links are a good start:
 

diff --git a/content/web-api-rest/reading/rest-practical-fundamentals/_index.md b/content/web-api-rest/reading/rest-practical-fundamentals/_index.md
@@ -7,9 +7,9 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Sally Steuterman # to be set by the page reviewer
 reviewerGitHub: gildedgardenia # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Terri Penn # update any time edits are made after review
+lastEditorGitHub: tpenn # update any time edits are made after review
+lastMod: 2024-01-01T06:59:25-06:00 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 Here's a takeaway of the abstract ideas we covered on the last page:
@@ -99,7 +99,7 @@ Endpoints are what an API exposes to its consumers. Each endpoint is made up of
 
 ### Identifying the Resource
 
-Paths are used to identify the resource being interacted with. Recall the hierarchal nature of resources where an entity only 
+Paths are used to identify the resource being interacted with. Recall the hierarchical nature of resources where an entity only 
 exists within a collection. RESTful APIs separate the resources they expose into one or more resource entry-points.
 
 Let's consider two resources exposed by a RESTful API:
@@ -211,7 +211,7 @@ Depending on the endpoint, the effect of a request can differ. In other words, t
 | `DELETE` | `remove all entities in the collection` |
 
 {{% notice blue "Note" "rocket" %}}
-Exposing the ability to modify or delete all of the entities in a collection at once can be risky. In many cases, the design of a RESTful API will only support `GET` and `POST` endpoints for collections. 
+Exposing the ability to modify or delete all the entities in a collection at once can be risky. In many cases, the design of a RESTful API will only support `GET` and `POST` endpoints for collections. 
 {{% /notice %}}
 
 Let's consider a request for creating a resource entity. Recall that this operation acts on the state of the collection by 
@@ -310,18 +310,18 @@ status codes and messages notify the consumer of the changes needed for a succes
 
 Let's look at some of the common client error status codes:
 
-| Status Code | Message | Correction |
-|-----|-----|-----|
-| `400` | `Bad Request` | Client must fix errors in their request body |
-| `401`| `Unauthorized` | Client must authenticate first |
-| `403` | `Forbidden` | An Authenticated client in not allowed to perform the requested action |
+| Status Code | Message | Correction                                                                    |
+|-----|-----|-------------------------------------------------------------------------------|
+| `400` | `Bad Request` | Client must fix errors in their request body                                  |
+| `401`| `Unauthorized` | Client must authenticate first                                                |
+| `403` | `Forbidden` | An Authenticated client is not allowed to perform the requested action        |
 | `404` | `Not Found` | The path to identify the resource is incorrect or the resource does not exist |
 
 
 A bad request will include an error message in its response. The message should indicate what the client must change in their request body to succeed. This failure is seen when creating or updating a resource entity:
 
 {{% notice blue "Example" "rocket" %}}
-In the upcoming SpringRestApiApplication, the state of a `Event` is validated using the following criteria:
+In the upcoming SpringRestApiApplication, the state of an `Event` is validated using the following criteria:
 
 - `name`: "string text"
 - `description`: "string text"

diff --git a/content/web-api-rest/reading/what-is-rest/_index.md b/content/web-api-rest/reading/what-is-rest/_index.md
@@ -7,9 +7,9 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Sally Steuterman # to be set by the page reviewer
 reviewerGitHub: gildedgardenia # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Terri Penn # update any time edits are made after review
+lastEditorGitHub: tpenn # update any time edits are made after review
+lastMod: 2024-01-01T06:46:43-06:00 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 **REST** is an acronym that stands for **REpresentational State Transfer**. **RESTful web services** refer to web technologies that use
@@ -144,8 +144,8 @@ In order to fulfill these operations, you need to know:
 - what collection the entity belongs to
 - how to uniquely identify the entity within the collection
 
-This hierarchal relationship between collections and the entities within them is an integral aspect of RESTful design. The contract of a RESTful API 
-defines the shape, or structure, of its resources along with the hierarchal organization of the endpoints used for interacting with them.
+This hierarchical relationship between collections and the entities within them is an integral aspect of RESTful design. The contract of a RESTful API 
+defines the shape, or structure, of its resources along with the hierarchical organization of the endpoints used for interacting with them.
 
 ### Check Your Understanding
 

diff --git a/content/web-api-rest/studio/_index.md b/content/web-api-rest/studio/_index.md
@@ -7,9 +7,9 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Sally Steuterman # to be set by the page reviewer
 reviewerGitHub: gildedgardenia # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Terri Penn # update any time edits are made after review
+lastEditorGitHub: tpenn # update any time edits are made after review
+lastMod: 2024-01-01T16:02:52-06:00 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 The UI of a browser is designed to make simple `GET` requests for URLs entered into its address bar. This design works great for browsing sites, but falls short when working with APIs. Anything beyond a `GET` request is difficult to send via a browser address bar alone. Think about what is needed to create a new `Event`. This type of request contains a body. Our MVC application included a view to allow us to test inputs. Our API, however, is **headless**. It does not contain the client-side form. In order to test how it handles requests then, we need a way to interact with the API server without the browser. In this studio, we work with Postman to explore how APIs can be consumed.
@@ -25,7 +25,7 @@ If you haven't done so already, [install Postman]({{< relref "../../../appendice
 With Postman installed, we're ready to fork and clone the [API located here](https://github.com/LaunchCodeEducation/events-api). Although it is implemented differently from CodingEvents MVC, you will find that most of the features from the MVC application have been supported through endpoints in the API.
 
 {{% notice blue "Note" "rocket" %}}
-Our focus in this studio is on operations and as such we will not be going into the development of the API. However, feel free to explore the source code if you are curious about the similarities and differences between the .NET MVC and API implementations.
+Our focus in this studio is on operations and as such we will not be going into the development of the API. However, feel free to explore the source code if you are curious about the similarities and differences between the Spring MVC and API implementations.
 {{% /notice %}}
 
 ### Start the API Server
@@ -34,7 +34,7 @@ Open the project within IntelliJ and start the application.
 
 ### Swagger Documentation
 
-This application also implements [Swagger](https://swagger.io/) for an api documentation page. Once your application is running you can view the swagger docs here at the following location: http://localhost:8080/swagger-ui/index.html.
+This application also implements [Swagger](https://swagger.io/) for an API documentation page. Once your application is running you can view the Swagger docs here at the following location: http://localhost:8080/swagger-ui/index.html.
 
 You'll see a page that looks nothing like any view we created in our other MVC applications. What you see running in the browser is not at all a client-side application, but rather, some documentation resources for the API itself.