fixed typos and broken links

Author: SeaJayEm

core/data-persisters.md

@@ -11,11 +11,11 @@ A [Doctrine MongoDB ODM](https://www.doctrine-project.org/projects/mongodb-odm.h
 
 However, you may want to:
 
-* store data to other persistence layers (ElasticSearch, external web services...)
+* store data to other persistence layers (Elasticsearch, external web services...)
 * not publicly expose the internal model mapped with the database through the API
 * use a separate model for [read operations](data-providers.md) and for updates by implementing patterns such as [CQRS](https://martinfowler.com/bliki/CQRS.html)
 
-Custom data persisters can be used to do so. A project can include as many data persisters as it needs. The first able to
+Custom data persisters can be used to do so. A project can include as many data persisters as needed. The first able to
 persist data for a given resource will be used.
 
 ## Creating a Custom Data Persister
@@ -25,7 +25,7 @@ This interface defines only 3 methods:
 
 * `persist`: to create or update the given data
 * `remove`: to delete the given data
-* `support`: checks whether the given data is supported by this data persister
+* `support`: to check whether the given data is supported by this data persister
 
 Here is an implementation example:
 

core/data-providers.md

@@ -5,20 +5,20 @@ ORM](http://www.doctrine-project.org/projects/orm.html) to retrieve data from a
 [Doctrine MongoDB ODM](https://www.doctrine-project.org/projects/mongodb-odm.html) to retrieve data from a document
 database, and a data provider using [Elasticsearch-PHP](https://www.elastic.co/guide/en/elasticsearch/client/php-api/current/index.html)
 to retrieve data from an Elasticsearch cluster are included with the library. The first one is enabled by default. These
-data providers natively support paged collections and filters. They can be used as is and fits perfectly with common usages.
+data providers natively support paged collections and filters. They can be used as-is and are perfectly suited to common uses.
 
-However, you sometime want to retrieve data from other sources such as another persistence layer or a webservice.
-Custom data providers can be used to do so. A project can include as many data providers as it needs. The first able to
+However, you sometimes want to retrieve data from other sources such as another persistence layer or a webservice.
+Custom data providers can be used to do so. A project can include as many data providers as needed. The first able to
 retrieve data for a given resource will be used.
 
-For a given resource, you can implement two kind of interfaces:
+For a given resource, you can implement two kinds of interface:
 
 * the [`CollectionDataProviderInterface`](https://github.com/api-platform/core/blob/master/src/DataProvider/CollectionDataProviderInterface.php)
   is used when fetching a collection.
 * the [`ItemDataProviderInterface`](https://github.com/api-platform/core/blob/master/src/DataProvider/ItemDataProviderInterface.php)
   is used when fetching items.
 
-Both implementations can also implement a third, optional interface called
+Both implementations can also implement a third, optional, interface called
 ['RestrictedDataProviderInterface'](https://github.com/api-platform/core/blob/master/src/DataProvider/RestrictedDataProviderInterface.php)
 if you want to limit their effects to a single resource or operation.
 
@@ -167,7 +167,7 @@ final class BlogPostItemDataProvider implements ItemDataProviderInterface, Seria
 ## Injecting Extensions (Pagination, Filter, EagerLoading etc.)
 
 ApiPlatform provides a few extensions that you can reuse in your custom DataProvider.
-Note that there are a few kind of extensions which are detailed in [their own chapter of the documentation](extensions.md).
+Note that there are a few kinds of extensions which are detailed in [their own chapter of the documentation](extensions.md).
 Because extensions are tagged services, you can use the [injection of tagged services](https://symfony.com/blog/new-in-symfony-3-4-simpler-injection-of-tagged-services):
 
 ```yaml

core/design.md

@@ -32,7 +32,7 @@ For [Rapid Application Development](https://en.wikipedia.org/wiki/Rapid_applicat
 **if and only if the class marked with `@ApiResource` is also a Doctrine entity**, the developer can use the Doctrine
 ORM's data provider and persister implementations shipped with API Platform.
 
-In this case, the public (`@ApiResource`) and internal (Doctrine entity) data model are shared. Then, API Platform will
+In this case, the public (`@ApiResource`) and internal (Doctrine entity) data models are shared. Then, API Platform will
 be able to query, filter, paginate and persist data automatically.
 This approach is super-convenient and efficient, but is probably **not a good idea** for non-[CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)
 and/or large systems.

core/filters.md

@@ -1,7 +1,7 @@
 # Filters
 
 API Platform Core provides a generic system to apply filters on collections. Useful filters for the Doctrine ORM and
-MongoDB ODM are provided with the library. You can also create custom filters that would fit your specific needs.
+MongoDB ODM are provided with the library. You can also create custom filters that fit your specific needs.
 You can also add filtering support to your custom [data providers](data-providers.md) by implementing interfaces provided
 by the library.
 
@@ -127,19 +127,19 @@ If Doctrine ORM or MongoDB ODM support is enabled, adding filters is as easy as
 
 The search filter supports `exact`, `partial`, `start`, `end`, and `word_start` matching strategies:
 
-* `partial` strategy uses `LIKE %text%` to search for fields that containing the text.
-* `start` strategy uses `LIKE text%` to search for fields that starts with text.
-* `end` strategy uses `LIKE %text` to search for fields that ends with text.
-* `word_start` strategy uses `LIKE text% OR LIKE % text%` to search for fields that contains the word starting with `text`.
+* `partial` strategy uses `LIKE %text%` to search for fields that contain `text`.
+* `start` strategy uses `LIKE text%` to search for fields that start with `text`.
+* `end` strategy uses `LIKE %text` to search for fields that end with `text`.
+* `word_start` strategy uses `LIKE text% OR LIKE % text%` to search for fields that contain words starting with `text`.
 
 Prepend the letter `i` to the filter if you want it to be case insensitive. For example `ipartial` or `iexact`. Note that
 this will use the `LOWER` function and **will** impact performance [if there is no proper index](performance.md#search-filter).
 
 Case insensitivity may already be enforced at the database level depending on the [collation](https://en.wikipedia.org/wiki/Collation)
 used. If you are using MySQL, note that the commonly used `utf8_unicode_ci` collation (and its sibling `utf8mb4_unicode_ci`)
-are already case insensitive, as indicated by the `_ci` part in their names.
+are already case-insensitive, as indicated by the `_ci` part in their names.
 
-Note: Search filters with the exact strategy can have multiple values for a same property (in this case the condition will be similar to a SQL IN clause).
+Note: Search filters with the `exact` strategy can have multiple values for the same property (in this case the condition will be similar to a SQL IN clause).
 
 Syntax: `?property[]=foo&property[]=bar`
 
@@ -191,22 +191,22 @@ class Offer
 ```
 
 With this service definition, it is possible to find all offers belonging to the product identified by a given IRI.
-Try the following: `http://localhost:8000/api/offers?product=/api/products/12`
+Try the following: `http://localhost:8000/api/offers?product=/api/products/12`.
 Using a numeric ID is also supported: `http://localhost:8000/api/offers?product=12`
 
-Previous URLs will return all offers for the product having the following IRI as JSON-LD identifier (`@id`): `http://localhost:8000/api/products/12`.
+The above URLs will return all offers for the product having the following IRI as JSON-LD identifier (`@id`): `http://localhost:8000/api/products/12`.
 
 ### Date Filter
 
-The date filter allows for filtering a collection by date intervals.
+The date filter allows to filter a collection by date intervals.
 
 Syntax: `?property[<after|before|strictly_after|strictly_before>]=value`
 
 The value can take any date format supported by the [`\DateTime` constructor](http://php.net/manual/en/datetime.construct.php).
 
 The `after` and `before` filters will filter including the value whereas `strictly_after` and `strictly_before` will filter excluding the value.
 
-As others filters, the date filter must be explicitly enabled:
+Like others filters, the date filter must be explicitly enabled:
 
 ```php
 <?php
@@ -245,7 +245,7 @@ Consider items as oldest             | `ApiPlatform\Core\Bridge\Doctrine\Orm\Fil
 Consider items as youngest           | `ApiPlatform\Core\Bridge\Doctrine\Orm\Filter\DateFilter::INCLUDE_NULL_AFTER` (`include_null_after`)
 Always include items                 | `ApiPlatform\Core\Bridge\Doctrine\Orm\Filter\DateFilter::INCLUDE_NULL_BEFORE_AND_AFTER` (`include_null_before_and_after`)
 
-For instance, exclude entries with a property value of `null`, with the following service definition:
+For instance, exclude entries with a property value of `null` with the following service definition:
 
 ```php
 <?php
@@ -359,15 +359,15 @@ class Offer
 }
 ```
 
-Given that the collection endpoint is `/offers`, you can filters the price with the following query: `/offers?price[between]=12.99..15.99`.
+Given that the collection endpoint is `/offers`, you can filter the price with the following query: `/offers?price[between]=12.99..15.99`.
 
 It will return all offers with `price` between 12.99 and 15.99.
 
 You can filter offers by joining two values, for example: `/offers?price[gt]=12.99&price[lt]=19.99`.
 
 ### Exists Filter
 
-The exists filter allows you to select items based on nullable field value.
+The exists filter allows you to select items based on a nullable field value.
 
 Syntax: `?property[exists]=<true|false|1|0>`
 
@@ -553,9 +553,9 @@ class Offer
 }
 ```
 
-**Note: Filters on nested properties must still be enabled explicitly, in order to keep things sane**
+**Note: Filters on nested properties must still be enabled explicitly, in order to keep things sane.**
 
-Regardless of this option, filters can by applied on a property only if:
+Regardless of this option, filters can be applied on a property only if:
 
 * the property exists
 * the value is supported (ex: `asc` or `desc` for the order filters).
@@ -1003,12 +1003,12 @@ class AndOperatorFilterExtension implements RequestBodySearchCollectionExtension
 
 ### Using Doctrine ORM Filters
 
-Doctrine ORM features [a filter system](http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/filters.html) that allows the developer to add SQL to the conditional clauses of queries, regardless the place where the SQL is generated (e.g. from a DQL query, or by loading associated entities).
-These are applied on collections and items, so are incredibly useful.
+Doctrine ORM features [a filter system](http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/filters.html) that allows the developer to add SQL to the conditional clauses of queries, regardless of the place where the SQL is generated (e.g. from a DQL query, or by loading associated entities).
+These are applied on collections and items and therefore are incredibly useful.
 
 The following information, specific to Doctrine filters in Symfony, is based upon [a great article posted on Michaël Perrin's blog](http://blog.michaelperrin.fr/2014/12/05/doctrine-filters/).
 
-Suppose we have a `User` entity and an `Order` entity related to the `User` one. A user should only see his orders and no others's ones.
+Suppose we have a `User` entity and an `Order` entity related to the `User` one. A user should only see his orders and no one else's.
 
 ```php
 <?php
@@ -1157,7 +1157,7 @@ doctrine:
                 class: App\Filter\UserFilter
 ```
 
-And add a listener for every request that initializes the Doctrine filter with the current user in your bundle services declaration file.
+Add a listener for every request that initializes the Doctrine filter with the current user in your bundle services declaration file.
 
 ```yaml
 # api/config/services.yaml
@@ -1266,13 +1266,13 @@ class DummyCar
 
 ```
 
-On the first property, `name`, it's straightforward. The first annotation argument is the filter class, the second specifies options, here the strategy:
+On the first property, `name`, it's straightforward. The first annotation argument is the filter class, the second specifies options, here, the strategy:
 
 ```
 @ApiFilter(SearchFilter::class, strategy="partial")
 ```
 
-The second annotation, we specify `properties` on which the filter should apply. It's necessary here because we don't want to filter `colors` but the property `prop` of the `colors` association.
+In the second annotation, we specify `properties` on which the filter should apply. It's necessary here because we don't want to filter `colors` but the `prop` property of the `colors` association.
 Note that for each given property we specify the strategy:
 
 ```
@@ -1314,13 +1314,13 @@ class DummyCar
 
 ```
 
-The `BooleanFilter` is applied to every `Boolean` property of the class. Indeed, in each core filters we check the Doctrine type. It's written only by using the filter class:
+The `BooleanFilter` is applied to every `Boolean` property of the class. Indeed, in each core filter we check the Doctrine type. It's written only by using the filter class:
 
 ```
 @ApiFilter(BooleanFilter::class)
 ```
 
-The `DateFilter` given here will be applied to every `Date` property of the class `DummyCar` with the `DateFilter::EXCLUDE_NULL` strategy:
+The `DateFilter` given here will be applied to every `Date` property of the `DummyCar` class with the `DateFilter::EXCLUDE_NULL` strategy:
 
 ```
 @ApiFilter(DateFilter::class, strategy=DateFilter::EXCLUDE_NULL)
@@ -1334,7 +1334,7 @@ The `SearchFilter` here adds properties. The result is the exact same as the exa
 
 Note that you can specify the `properties` argument on every filter.
 
-The next filters are not related to how the data is fetched but rather on the how the serialization is done on those, we can give an `arguments` option ([see here for the available arguments](#serializer-filters)):
+The next filters are not related to how the data is fetched but rather to how the serialization is done on those. We can give an `arguments` option ([see here for the available arguments](#serializer-filters)):
 
 ```
 @ApiFilter(PropertyFilter::class, arguments={"parameterName": "foobar"})

core/getting-started.md

@@ -3,18 +3,18 @@
 ## Installing API Platform Core
 
 If you are starting a new project, the easiest way to get API Platform up is to install the [API Platform Distribution](../distribution/index.md).
-It ships with the API Platform Core library integrated with [the Symfony framework](https://symfony.com), [the schema generator](../schema-generator/),
+It comes with the API Platform Core library integrated with [the Symfony framework](https://symfony.com), [the schema generator](../schema-generator/),
 [Doctrine ORM](http://www.doctrine-project.org), [Elasticsearch-PHP](https://www.elastic.co/guide/en/elasticsearch/client/php-api/current/index.html),
 [NelmioCorsBundle](https://github.com/nelmio/NelmioCorsBundle) and [Behat](http://behat.org).
 [Doctrine MongoDB ODM](https://www.doctrine-project.org/projects/mongodb-odm.html) can also be enabled by following the [MongoDB documentation](mongodb.md).
 Basically, it is a Symfony edition packaged with the best tools to develop a REST API and sensible default settings.
 
-Alternatively, you can use [Composer](http://getcomposer.org) to install the standalone bundle in an existing Symfony Flex
+Alternatively, you can use [Composer](http://getcomposer.org) to install the stand-alone bundle in an existing Symfony Flex
 project:
 
 `composer require api`
 
-There is no mandatory configuration options although [many settings are available](configuration.md).
+There are no mandatory configuration options although [many settings are available](configuration.md).
 
 ## Before Reading this Documentation
 
@@ -70,15 +70,15 @@ class Product // The class name will be used to name exposed resources
 
     public function __construct()
     {
-        $this->offers = new ArrayCollection(); // Initialize $offers as an Doctrine collection
+        $this->offers = new ArrayCollection(); // Initialize $offers as a Doctrine collection
     }
 
     public function getId(): ?int
     {
         return $this->id;
     }
 
-    // Adding both an adder and a remover as well as updating the reverse relation are mandatory
+    // Adding both an adder and a remover as well as updating the reverse relation is mandatory
     // if you want Doctrine to automatically update and persist (thanks to the "cascade" option) the related entity
     public function addOffer(Offer $offer): void
     {
@@ -147,18 +147,18 @@ web API.
 If you are familiar with the Symfony ecosystem, you noticed that entity classes are also mapped with Doctrine ORM annotations
 and validation constraints from [the Symfony Validator Component](http://symfony.com/doc/current/book/validation.html).
 This isn't mandatory. You can use [your preferred persistence](data-providers.md) and [validation](validation.md) systems.
-However, API Platform Core has built-in support for those library and is able to use them without requiring any specific
-code or configuration to automatically persist and validate your data. They are good default and we encourage you to use
+However, API Platform Core has built-in support for those libraries and is able to use them without requiring any specific
+code or configuration to automatically persist and validate your data. They are a good default option and we encourage you to use
 them unless you know what you are doing.
 
 Thanks to the mapping done previously, API Platform Core will automatically register the following REST [operations](operations.md)
 for resources of the product type:
 
-Product
+*Product*
 
 Method | URL            | Description
 -------|----------------|--------------------------------
-GET    | /products      | Retrieve the (paged) collection
+GET    | /products      | Retrieve the (paginated) collection
 POST   | /products      | Create a new product
 GET    | /products/{id} | Retrieve a product
 PUT    | /products/{id} | Update a product
@@ -184,7 +184,7 @@ XML:
     <resource
         class="App\Entity\Offer"
         shortName="Offer" <!-- optional -->
-        description="An offer form my shop" <!-- optional -->
+        description="An offer from my shop" <!-- optional -->
         iri="http://schema.org/Offer" <!-- optional -->
     />
 </resources>
@@ -222,6 +222,6 @@ If you want to serialize only a subset of your data, please refer to the [Serial
 You now have a fully featured API exposing your entities.
 Run the Symfony app (`bin/console server:run`) and browse the API entrypoint at `http://localhost:8000/api`.
 
-Interact with the API using a REST client (we recommend [Postman](https://www.getpostman.com/)) or an Hydra aware application
+Interact with the API using a REST client (we recommend [Postman](https://www.getpostman.com/)) or an Hydra-aware application
 (you should give [Hydra Console](https://github.com/lanthaler/HydraConsole) a try). Take
 a look at the usage examples in [the `features` directory](https://github.com/api-platform/core/tree/master/features).

core/graphql.md

@@ -4,7 +4,7 @@
 
 [GraphQL](http://graphql.org/) is a query language made to communicate with an API and therefore is an alternative to REST.
 
-It has some advantages compared to REST: it solves the over-fetching or under-fetching of data, is strongly typed, and is capable of retrieving multiple and nested data in one time; but it also comes with drawbacks: for example it creates overhead depending of the request.
+It has some advantages compared to REST: it solves the over-fetching or under-fetching of data, is strongly typed, and is capable of retrieving multiple and nested data in one go, but it also comes with drawbacks. For example it creates overhead depending on the request.
 
 API Platform creates a REST API by default. But you can choose to enable GraphQL as well.