Improve documentation and code comments: spelling grammar tone

Author: bkoelman

docs/usage/advanced/error-handling.md

@@ -3,7 +3,7 @@
 The code [here](https://github.com/json-api-dotnet/JsonApiDotNetCore/tree/master/test/JsonApiDotNetCoreTests/IntegrationTests/ExceptionHandling) shows how to customize error handling.
 
 A user-defined exception, `ConsumerArticleIsNoLongerAvailableException`, is thrown from a resource service to demonstrate handling it.
-Note that this exception can be thrown from anywhere during request execution; a resource service is just used here for simplicity.
+Note that this exception can be thrown from anywhere during request execution; a resource service is used here for simplicity.
 
 To handle the user-defined exception, `AlternateExceptionHandler` inherits from `ExceptionHandler` to:
 - Customize the JSON:API error response by adding a `meta` entry when `ConsumerArticleIsNoLongerAvailableException` is thrown.

docs/usage/common-pitfalls.md

@@ -73,8 +73,8 @@ the richness of JSON:API. For example, it enables users to include related resou
 As an API developer, you'll benefit from rich input validation and fine-grained control for setting what's permitted when users access relationships.
 
 #### Model relationships instead of complex (JSON) attributes
-Similar to the above, returning a complex object takes away all the relationship features of JSON:API. Users can't filter inside a complex object. Or update
-a nested value, without risking accidentally overwriting another unrelated nested value from a concurrent request. Basically, there's no partial PATCH to prevent that.
+Similar to the above, returning a complex object takes away all the relationship features of JSON:API. Users can't filter inside a complex object, nor update
+a nested value without risking accidentally overwriting another unrelated nested value from a concurrent request. There's no partial PATCH to prevent that.
 
 #### Stay away from stored procedures
 There are [many reasons](https://stackoverflow.com/questions/1761601/is-the-usage-of-stored-procedures-a-bad-practice/9483781#9483781) to not use stored procedures.

docs/usage/extensibility/controllers.md

@@ -123,7 +123,7 @@ To provide read-only access, inherit from `JsonApiQueryController` instead, whic
 Likewise, to provide write-only access, inherit from `JsonApiCommandController`, which blocks all GET and HEAD requests.
 
 You can even make your own mix of allowed routes by calling the alternate constructor of `JsonApiController` and injecting the set of service implementations available.
-In some cases, resources may be an aggregation of entities or a view on top of the underlying entities. In these cases, there may not be a writable `IResourceService` implementation, so simply inject the implementation that is available.
+In some cases, resources may be an aggregation of entities or a view on top of the underlying entities. In these cases, there may not be a writable `IResourceService` implementation. Inject the implementation that is available.
 
 ```c#
 public class ReportsController : JsonApiController<Report, long>
@@ -189,4 +189,3 @@ partial class TagsController
         return Ok(defaultTags);
     }
 }
-```

docs/usage/extensibility/query-strings.md

@@ -21,7 +21,7 @@ See [here](~/usage/extensibility/resource-definitions.md#custom-query-string-par
 
 ## Custom query string parsing
 
-In order to add parsing of custom query string parameters, you can implement the `IQueryStringParameterReader` interface and register your reader.
+To add parsing of custom query string parameters, implement the `IQueryStringParameterReader` interface and register your reader.
 
 ```c#
 public class CustomQueryStringParameterReader : IQueryStringParameterReader

docs/usage/extensibility/services.md

@@ -111,7 +111,7 @@ IResourceCommandService <|-- ISetRelationshipService
 IResourceCommandService <|-- IRemoveFromRelationshipService
 ```
 
-In order to take advantage of these interfaces you first need to register the service for each implemented interface.
+To take advantage of these interfaces, register the service for each implemented interface.
 
 ```c#
 public class ArticleService : ICreateService<Article, long>, IDeleteService<Article, long>
@@ -158,4 +158,3 @@ public class ArticlesController : JsonApiController<Article, long>
     {
     }
 }
-```

docs/usage/faq.md

@@ -64,7 +64,8 @@ Aside from debugging, you can get more info by:
 
 #### What if my JSON:API resources do not exactly match the shape of my database tables?
 We often find users trying to write custom code to solve that. They usually get it wrong or incomplete, and it may not perform well.
-Or it simply fails because it cannot be translated to SQL.
+Alternatively, it might fail because it cannot be translated to SQL.
+
 The good news is that there's an easier solution most of the time: configure Entity Framework Core mappings to do the work.
 
 For example, if your primary key column is named "CustomerId" instead of "Id":

docs/usage/resources/nullability.md

@@ -60,7 +60,7 @@ public sealed class Label : Identifiable<long>
 
 When NRT is turned on, use nullability annotations (?) on attributes and relationships. This makes Entity Framework Core generate non-nullable columns. And model errors are returned when non-nullable fields are omitted.
 
-The [Entity Framework Core guide on NRT](https://learn.microsoft.com/ef/core/miscellaneous/nullable-reference-types) recommends to use constructor binding to initialize non-nullable properties, but JsonApiDotNetCore does not support that. For required navigation properties, it suggests to use a non-nullable property with a nullable backing field. JsonApiDotNetCore does not support that either. In both cases, just use the null-forgiving operator (!).
+The [Entity Framework Core guide on NRT](https://learn.microsoft.com/ef/core/miscellaneous/nullable-reference-types) recommends using constructor binding to initialize non-nullable properties, but JsonApiDotNetCore does not support that. For required navigation properties, it suggests using a non-nullable property with a nullable backing field. JsonApiDotNetCore does not support that either. In both cases, use the null-forgiving operator (!).
 
 When ModelState validation is turned on, to-many relationships must be assigned an empty collection. Otherwise an error is returned when they don't occur in the request body.
 
@@ -86,4 +86,3 @@ public sealed class Label : Identifiable<long>
     [HasMany]
     public ISet<TodoItem> TodoItems { get; set; } = new HashSet<TodoItem>();
 }
-```

src/Examples/DapperExample/FromEntitiesNavigationResolver.cs

@@ -32,7 +32,7 @@ public FromEntitiesNavigationResolver(IResourceGraph resourceGraph, FromEntities
 
     public void Resolve()
     {
-        // In order to produce SQL, some knowledge of the underlying database model is required.
+        // To produce SQL, some knowledge of the underlying database model is required.
         // Because the database in this example project is created using Entity Framework Core, we derive that information from its model.
         // Some alternative approaches to consider:
         // - Query the database to obtain model information at startup.

src/JsonApiDotNetCore.OpenApi.Swashbuckle/SwaggerComponents/DocumentationOpenApiOperationFilter.cs

@@ -239,12 +239,12 @@ private void ApplyPostResource(OpenApiOperation operation, ResourceType resource
         SetResponseDescription(operation.Responses, HttpStatusCode.Created,
             $"The {singularName} was successfully created, which resulted in additional changes. The newly created {singularName} is returned.");
 
-        SetResponseHeaderLocation(operation.Responses, HttpStatusCode.Created, singularName);
+        setResponseHeaderLocation(operation.Responses, HttpStatusCode.Created, singularName);
 
         SetResponseDescription(operation.Responses, HttpStatusCode.NoContent,
             $"The {singularName} was successfully created, which did not result in additional changes.");
 
-        SetResponseDescription(operation.Responses, HttpStatusCode.BadRequest, TextQueryStringOrRequestBodyBad);
+        setResponseDescription(operation.Responses, HttpStatusCode.BadRequest, TextQueryStringOrRequestBodyBad);
 
         ClientIdGenerationMode clientIdGeneration = resourceType.ClientIdGeneration ?? _options.ClientIdGeneration;
 
@@ -615,7 +615,7 @@ private static void ApplyPostOperations(OpenApiOperation operation)
 
         SetResponseDescription(operation.Responses, HttpStatusCode.BadRequest, TextRequestBodyBad);
         SetResponseDescription(operation.Responses, HttpStatusCode.Forbidden, "An operation is not accessible or a client-generated ID is used.");
-        SetResponseDescription(operation.Responses, HttpStatusCode.NotFound, "A resource or a related resource does not exist.");
+        setResponseDescription(operation.Responses, HttpStatusCode.NotFound, "A resource or a related resource does not exist.");
         SetResponseDescription(operation.Responses, HttpStatusCode.Conflict, TextConflict);
         SetResponseDescription(operation.Responses, HttpStatusCode.UnprocessableEntity, TextRequestBodyValidationFailed);
     }

src/JsonApiDotNetCore/Configuration/JsonApiOptions.cs

@@ -106,9 +106,9 @@ public bool AllowClientGeneratedIds
     public JsonSerializerOptions SerializerOptions { get; } = new()
     {
         // These are the options common to serialization and deserialization.
-        // At runtime, we actually use SerializerReadOptions and SerializerWriteOptions, which are customized copies of these settings,
+        // At runtime, we use SerializerReadOptions and SerializerWriteOptions, which are customized copies of these settings,
         // to overcome the limitation in System.Text.Json that the JsonPath is incorrect when using custom converters.
-        // Therefore we try to avoid using custom converters has much as possible.
+        // Therefore we minimize custom converter usage.
         // https://github.com/Tarmil/FSharp.SystemTextJson/issues/37
         // https://github.com/dotnet/runtime/issues/50205#issuecomment-808401245