diff --git a/docs/site/LB3-vs-LB4-request-response-cycle.md b/docs/site/LB3-vs-LB4-request-response-cycle.md
index 6d60e915af89..aea2ab8bd381 100644
--- a/docs/site/LB3-vs-LB4-request-response-cycle.md
+++ b/docs/site/LB3-vs-LB4-request-response-cycle.md
@@ -254,9 +254,8 @@ The request/response architecture has undergone a drastic change in LoopBack 4.
 LoopBack 3's
 [phase-based middleware routing system](https://loopback.io/doc/en/lb3/Routing.html)
 is now replaced by a
-[sequence handler](./apidocs/apidocs.rest.defaultsequence.md)
-that sits infront of a
-[routing table](./apidocs/apidocs.rest.routingtable.md).
+[sequence handler](./apidocs/apidocs.rest.defaultsequence.md) that sits infront
+of a [routing table](./apidocs/apidocs.rest.routingtable.md).
 
 In LoopBack 3, middleware are added using Express APIs and via phases in
 `middleware.json` or using
@@ -372,10 +371,10 @@ thus have access to the request and response objects.
 LoopBack 4, refer to the
 [validation doc](./Validation.md)." %}
 
-[strong-remoting](https://github.com/strongloop/strong-remoting) is the core
-of data coercion and validation in LoopBack 3. Validation rules are defined
-using the `accepts` metadata and data-access level
-validation are defined by model validation methods like `validatesPresenceOf()`.
+[strong-remoting](https://github.com/strongloop/strong-remoting) is the core of
+data coercion and validation in LoopBack 3. Validation rules are defined using
+the `accepts` metadata and data-access level validation are defined by model
+validation methods like `validatesPresenceOf()`.
 
 `strong-remoting`'s supported data types can be found in its
 [type definitions](https://github.com/strongloop/strong-remoting/tree/master/lib/types)
@@ -388,34 +387,34 @@ LoopBack 4 does a full JSON Schema validation at the REST layer and
 property-based validation at the data-access layer.
 
 OpenAPI is used to describe the type and constraints of request parameters in
-LoopBack 4. In a typical controller, OpenAPI schemas describing the model
-data are built from the metadata provided by LoopBack Models. Non-model
-parameters (e.g. id in `findById(id)`, `filter` in `find(filter)`) are
-described using inline schema.
+LoopBack 4. In a typical controller, OpenAPI schemas describing the model data
+are built from the metadata provided by LoopBack Models. Non-model parameters
+(e.g. id in `findById(id)`, `filter` in `find(filter)`) are described using
+inline schema.
 
 When a request arrives, a light weight
 [coercion](https://github.com/strongloop/loopback-next/blob/master/packages/rest/src/coercion/coerce-parameter.ts)
 and
 [validation](https://github.com/strongloop/loopback-next/blob/master/packages/rest/src/coercion/validator.ts)
-is performed on the request body at OpenAPI parameters level. Then, the
-OpenAPI schema is converted to JSON schema on which
+is performed on the request body at OpenAPI parameters level. Then, the OpenAPI
+schema is converted to JSON schema on which
 [AJV validation](https://github.com/strongloop/loopback-next/tree/master/packages/rest/src/validation)
 is run against the schema.
 
 Currently, LoopBack 4 does not validate non-body parameters against schema. It
 will be supported in future, follow
-[this issue](https://github.com/strongloop/loopback-next/issues/1573)
-to keep track of the progress.
+[this issue](https://github.com/strongloop/loopback-next/issues/1573) to keep
+track of the progress.
 
 In LoopBack 4, it is possible to apply additional validation of model data at
 the REST layer via `jsonSchema` model setting, which can partially replace
-advanced validations provided by LoopBack 3 at data-access level. However, it
-is not a direct replacement for Model validation methods in LoopBack 3. The
-former performs the validation at the REST API layer, while the later performs
-the validation at the data access layer; that means, the data validation of
+advanced validations provided by LoopBack 3 at data-access level. However, it is
+not a direct replacement for Model validation methods in LoopBack 3. The former
+performs the validation at the REST API layer, while the later performs the
+validation at the data access layer; that means, the data validation of
 `jsonSchema` will not be applied if data is modifiued using repository methods.
 
-Here is an example of enforcing the string length of a model property usin
+Here is an example of enforcing the string length of a model property using
 `jsonSchema` in LoopBack 4:
 
 ```ts