diff -u b/jsonapi.api.php b/jsonapi.api.php
--- b/jsonapi.api.php
+++ b/jsonapi.api.php
@@ -11,42 +11,45 @@
  *
  * @section overview Overview
  * The JSON API module is a Drupal-centric implementation of the JSON API
- * specification (the spec). By its own definition, the JSON API spec is "is a
+ * specification. By its own definition, the JSON API specification is "is a
  * specification for how a client should request that resources be fetched or
  * modified, and how a server should respond to those requests. [It] is designed
  * to minimize both the number of requests and the amount of data transmitted
  * between clients and servers. This efficiency is achieved without compromising
  * readability, flexibility, or discoverability."
  *
- * While "Drupal-centric", the JSON API is committed to strict compliance with
- * the spec. Wherever possible, the module attempts to implement the spec in a
- * way which is compatible and familiar with the patterns and concepts inherent
- * to Drupal. However, when "Drupalisms" cannot be reconciled with the spec,
- * the module will always choose the implementation most faithful to the spec.
+ * While "Drupal-centric", the JSON API module is committed to strict compliance
+ * with the specification. Wherever possible, the module attempts to implement
+ * the specification in a way which is compatible and familiar with the patterns
+ * and concepts inherent to Drupal. However, when "Drupalisms" cannot be
+ * reconciled with the specification, the module will always choose the
+ * implementation most faithful to the specification.
  *
  * @see http://jsonapi.org/
  *
  *
  * @section resources Resources
- * Every unit of data in the spec is a "resource". The spec defines how a client
- * should interact with a server to fetch and manipulate these resources.
- *
- * The JSON API module maps every entity type and bundle to a resource type.
- * Since the spec does not have a concept of resource type inheritance or
- * composition, the JSON API module implements different bundles of the same
+ * Every unit of data in the specification is a "resource". The specification
+ * defines how a client should interact with a server to fetch and manipulate
+ * these resources.
+ *
+ * The JSON API module maps every entity type + bundle to a resource type.
+ * Since the specification does not have a concept of resource type inheritance
+ * or composition, the JSON API module implements different bundles of the same
  * entity type as *distinct* resource types.
  *
  * While it is theoretically possible to expose arbitrary data as resources, the
- * JSON API module only derives resources from (config and content) entities.
+ * JSON API module only exposes resources from (config and content) entities.
  * This eliminates the need for another abstraction layer in order implement
  * certain features of the specification.
  *
  *
  * @section relationships Relationships
- * The spec defines semantics for the "relationships" between resources. Since
- * the JSON API module defines every entity type + bundle as a resource type and
- * does not allow non-entity resources, it is able to use entity references to
- * automatically define and represent the relationships between all resources.
+ * The specification defines semantics for the "relationships" between
+ * resources. Since the JSON API module defines every entity type + bundle as a
+ * resource type and does not allow non-entity resources, it is able to use
+ * entity references to automatically define and represent the relationships
+ * between all resources.
  *
  *
  * @section normalizers Normalizers
@@ -60,9 +63,9 @@
  * reference fields).
  *
  * This means that modules which provide additional field types must implement
- * normalizers at the "DataType" level. This is a level below "FieldType"
- * plugins. Modules which do not implement normalizers at this level risk that
- * their normalizers wll not be used by the JSON API module.
+ * normalizers at the "DataType" plugin level. This is a level below "FieldType"
+ * plugins. Normalizers which are not implemented at this level will not be used
+ * by the JSON API module.
  *
  * A benefit of implementing normalizers at this lower level is that they will
  * work automatically for both the JSON API module and core's REST module.
@@ -73,17 +76,19 @@
  * specification.
  *
  * The JSON API module provides *no PHP API to modify its behavior.* It is
- * designed to be configuration free.
+ * designed to have zero configuration.
  *
  * - Adding new resources/resource types is unsupported: all entities/entity
  *   types are exposed automatically. If you want to expose more data via the
  *   JSON API module, the data must be defined as entity. See the "Resources"
  *   section.
  * - Custom field normalization is not supported; only normalizers at the
- *   "DataType" plugin level are supported (these are a level below fields).
+ *   "DataType" plugin level are supported (these are a level below field
+ *   types).
+ *
+ * The JSON API module does provide a PHP API to generate a JSON API
+ * representation of entities:
  *
- * The JSON API module does provide a PHP API to generate JSON API compliant
- * serialization of entities:
  * @code
  * \Drupal::service('jsonapi.entity.to_jsonapi')->serialize($entity)
  * @endcode
@@ -106,7 +111,7 @@
  * What this means for developing consumers of the HTTP API is that *clients
  * should be implemented from the specification first and foremost.* This should
  * mitigate implicit dependencies on implementation details or inconsistencies
- * with the spec that are specific to this module.
+ * with the specification that are specific to this module.
  *
  * To help develop compatible clients, every response indicates the version of
  * the JSON API specification used under its "jsonapi" key. Future releases