docs: fix missing links and add consistency

Fixed missing links and added consistency.

Signed-off-by: Yaapa Hage <[email protected]>

docs/site/Application.md

@@ -132,7 +132,7 @@ The `component` function allows binding of component constructors within your
 `Application` instance's context.
 
 For more information on how to make use of components, see
-[Using Components](Components.md#using-components).
+[Using Components](Component.md#using-components).
 
 #### Controllers
 
@@ -142,7 +142,7 @@ app.controller(BarController);
 ```
 
 Much like the component function, the `controller` function allows binding of
-[Controllers](Controllers.md) to the `Application` context.
+[Controllers](Controller.md) to the `Application` context.
 
 #### Servers
 

docs/site/Booting-an-Application.md

@@ -189,7 +189,7 @@ are a part of the `@loopback/boot` package and loaded automatically via
 
 ### Controller Booter
 
-This Booter's purpose is to discover [Controller](Controllers.md) type Artifacts
+This Booter's purpose is to discover [Controller](Controller.md) type Artifacts
 and to bind them to the Application's Context.
 
 You can configure the conventions used in your project for a Controller by
@@ -223,10 +223,10 @@ passing a `models` object on `BootOptions` property of your Application. The
 
 ### Repository Booter
 
-This Booter's purpose is to discover [Repository](Repositories.md) type
-Artifacts and to bind them to the Application's Context. The use of this Booter
-requires `RepositoryMixin` from `@loopback/repository` to be mixed into your
-Application class.
+This Booter's purpose is to discover [Repository](Repository.md) type Artifacts
+and to bind them to the Application's Context. The use of this Booter requires
+`RepositoryMixin` from `@loopback/repository` to be mixed into your Application
+class.
 
 You can configure the conventions used in your project for a Repository by
 passing a `repositories` object on `BootOptions` property of your Application.
@@ -241,7 +241,7 @@ The `repositories` object supports the following options:
 
 ### DataSource Booter
 
-This Booter's purpose is to discover [DataSource](DataSources.md) type Artifacts
+This Booter's purpose is to discover [DataSource](DataSource.md) type Artifacts
 and to bind them to the Application's Context. The use of this Booter requires
 `RepositoryMixin` from `@loopback/repository` to be mixed into your Application
 class.

docs/site/Component.md

@@ -4,7 +4,9 @@ title: 'Component'
 keywords: LoopBack 4.0, LoopBack 4, Node.js, TypeScript, OpenAPI, Concepts
 sidebar: lb4_sidebar
 permalink: /doc/en/lb4/Component.html
-redirect_from: /doc/en/lb4/Components.html
+redirect_from:
+  - /doc/en/lb4/Components.html
+  - /doc/en/lb4/Using-components.html
 ---
 
 ## Overview
@@ -21,7 +23,7 @@ exporting a Component class which can be added to your application.
 Apart from its own properties, `Component` class can have the following
 properties:
 
-- `controllers` - An array of [controller](Controllers.md) classes.
+- `controllers` - An array of [controller](Controller.md) classes.
 - `providers` - A map of providers to be bound to the application
   [context](Context.md).
 - `classes` - A map of TypeScript classes to be bound to the application
@@ -43,7 +45,7 @@ your Application class. This doesn't change how a Component is registered
 (`app.component()`) but it enables the Component to contribute additional
 artifacts. For example:
 
-- [Repositories](Repositories.md) can be contributed by a Component by adding
+- [Repositories](Repository.md) can be contributed by a Component by adding
   `RepositoryMixin` from `@loopback/repository` to your Application
 - [Booters](Booting-an-Application.md#booters) can be contributed by a Component
   by adding `BootMixin` from `@loopback/boot` to your Application

docs/site/Behind-the-scene.md → docs/site/Concepts.md

@@ -1,9 +1,10 @@
 ---
 lang: en
-title: 'Behind the scenes'
+title: 'Concepts'
 keywords: LoopBack 4, Node.js, TypeScript, OpenAPI, Explanations, Concepts
 sidebar: lb4_sidebar
-permalink: /doc/en/lb4/Behind-the-scene.html
+permalink: /doc/en/lb4/Concepts.html
+redirect_from: /doc/en/lb4/Behind-the-scene.html
 ---
 
 LoopBack 4 defines some key building blocks to represent different
@@ -21,16 +22,16 @@ responsibilities for typical API and/or Microservice applications.
   typically listens on a specific endpoint (protocol/host/port), handles
   incoming requests, and then returns appropriate responses.
 
-- [**Controller**](Controllers.md): A class that implements operations defined
-  by the application’s REST API. It implements an application’s business logic
-  and acts as a bridge between the HTTP/REST API and domain/database models. A
+- [**Controller**](Controller.md): A class that implements operations defined by
+  the application’s REST API. It implements an application’s business logic and
+  acts as a bridge between the HTTP/REST API and domain/database models. A
   Controller operates only on processed input and abstractions of backend
   services / databases.
 
-- [**Interceptors**](Interceptors.md): A function that intercepts static or
+- [**Interceptor**](Interceptor.md): A function that intercepts static or
   instance method invocations on a class or object.
 
-- [**Route**](Routes.md): The mapping between your API specification and an
+- [**Route**](Route.md): The mapping between your API specification and an
   Operation. It tells LoopBack which Operation to `invoke()` when given an HTTP
   request.
 
@@ -43,10 +44,10 @@ responsibilities for typical API and/or Microservice applications.
   with DataSource Juggler. In addition, `@loopback/repository-json-schema`
   module uses the decorators' metadata to build a matching JSON Schema.
 
-- [**DataSources**](DataSources.md): A named configuration for a Connector
+- [**DataSource**](DataSource.md): A named configuration for a Connector
   instance that represents data in an external system.
 
-- [**Repository**](Repositories.md): A type of service that represents a
+- [**Repository**](Repository.md): A type of service that represents a
   collection of data within a DataSource.
 
 - [**Relation**](Relations.md): A mapping between two models which describes a
@@ -70,5 +71,5 @@ Here are the infrastructures that get all the artifacts working together:
   separate the construction of dependencies of a class or function from its
   behavior to keep the code loosely coupled.
 
-- [**Component**](Components.md): A package that bundles one or more LoopBack
+- [**Component**](Component.md): A package that bundles one or more LoopBack
   extensions.

docs/site/Controller.md

@@ -20,7 +20,7 @@ This page will only cover a `Controller`'s usage with REST APIs.
 
 ## Operations
 
-In the Operation example in [Routes](Routes.md), the `greet()` operation was
+In the Operation example in [Routes](Route.md), the `greet()` operation was
 defined as a plain JavaScript function. The example below shows this as a
 Controller method in TypeScript.
 

docs/site/Crafting-LoopBack-4.md

@@ -457,7 +457,7 @@ only for their middleware support). The final decision was to use Express in a
 way that bridges the gap by addressing the gaps identified above as follows:
 
 - LoopBack provides its own
-  [Controller / OpenAPI metadata optimized routing engine](Routes.md)
+  [Controller / OpenAPI metadata optimized routing engine](Route.md)
 - Express is used exclusively for allowing us to consume Express middleware
   (CORS, Static File Serving)
 - LoopBack uses a [Sequence of Actions](Sequence.md) to craft the response in a
@@ -473,7 +473,7 @@ There are several key pillars to make extensibility a reality for LoopBack 4.
 - [Context](Context.md), the IoC container to manage services
 - [Dependency injection](Dependency-injection.md) to facilitate composition
 - [Decorators](Decorators.md) to supply metadata using annotations
-- [Components](Components.md) as the packaging model to bundle extensions
+- [Components](Component.md) as the packaging model to bundle extensions
 
 Please check out [Extending LoopBack 4](Extending-LoopBack-4.md).
 
@@ -484,11 +484,10 @@ API experience by "eating your own dog food" with the following artifacts:
 
 - [Sequence and actions](Sequence.md): A sequence of actions to handle HTTP
   requests/responses.
-- [Controllers](Controllers.md): A class with methods to implement API
-  operations behind REST endpoints.
+- [Controllers](Controller.md): A class with methods to implement API operations
+  behind REST endpoints.
 - [Model](Model.md): Definition of data models.
-- [Repositories](Repositories.md): Interfaces of access patterns for data
-  sources.
+- [Repositories](Repository.md): Interfaces of access patterns for data sources.
 
 The features are provided by the following modules:
 

docs/site/Creating-CRUD-REST-apis.md

@@ -9,7 +9,7 @@ summary:
   datasource
 ---
 
-Starting with a [model class](Model.md) and [datasource](DataSources.md),
+Starting with a [model class](Model.md) and [datasource](DataSource.md),
 LoopBack 4 allows you to easily use CRUD REST APIs by convention through
 [`@loopback/rest-crud`](https://github.com/strongloop/loopback-next/tree/master/packages/rest-crud).
 The package allows the application to use a default CRUD repository and

docs/site/Creating-components.md

@@ -6,8 +6,8 @@ sidebar: lb4_sidebar
 permalink: /doc/en/lb4/Creating-components.html
 ---
 
-As explained in [Using Components](Components.md), a typical LoopBack component
-is an npm package exporting a Component class.
+As explained in [Using Components](Component.md#using-components), a typical
+LoopBack component is an npm package exporting a Component class.
 
 ```ts
 import {MyController} from './controllers/my.controller';

docs/site/DataSource-generator.md

@@ -10,7 +10,7 @@ permalink: /doc/en/lb4/DataSource-generator.html
 
 ### Synopsis
 
-Adds a new [DataSource](DataSources.md) class and config files to a LoopBack
+Adds a new [DataSource](DataSource.md) class and config files to a LoopBack
 application.
 
 ```sh

docs/site/Defining-the-API-using-code-first-approach.md

@@ -33,7 +33,7 @@ provide a description of your API. These concepts and their decorators include:
 - [Model](Model.md)
   - `@model()`
   - `@property()`
-- [Routes](Routes.md)
+- [Routes](Route.md)
   - `@operation()`
   - `@param()`
 

docs/site/Express-middleware.md

@@ -361,5 +361,5 @@ const binding = server.expressMiddleware('middleware.express.greeting', router);
 into LoopBack seamlessly. Please read the following pages to better understand
 the architecture.
 
-- [Interceptors](Interceptors.md)
+- [Interceptors](Interceptor.md)
 - [Middleware](Middleware.md)

docs/site/Extending-LoopBack-4.md

@@ -141,7 +141,7 @@ is illustrated below:
 For more information about components, see:
 
 - [Creating components](Creating-components.md)
-- [Using Components](Components.md#using-components)
+- [Using Components](Component.md#using-components)
 
 ## Types of extensions
 

docs/site/Getting-started.md

@@ -67,7 +67,7 @@ In a browser, visit <http://127.0.0.1:3000/ping>.
 ## Adding your own controller
 
 Now that we have a basic project created, it's time to add our own
-[controller](Controllers.md). Let's add a simple "Hello World" controller as
+[controller](Controller.md). Let's add a simple "Hello World" controller as
 follows:
 
 ```sh

docs/site/Glossary.md

@@ -17,9 +17,9 @@ paths, headers, and so on) a client needs to make a valid request to the API.
 
 **Application**: A container of components.
 
-**Component**: A reusable bundle of Bindings, [Controllers](Controllers.md),
-Services, [Repositories](Repositories.md), and models. For more information, see
-[Using components](Components.md#using-components) and
+**Component**: A reusable bundle of Bindings, [Controllers](Controller.md),
+Services, [Repositories](Repository.md), and models. For more information, see
+[Using components](Component.md#using-components) and
 [Creating components](Creating-components.md).
 
 **Connector**: An interface that abstracts underlying backend systems (for
@@ -48,4 +48,4 @@ responds to requests.
 **Service**: Operations implemented in an external system.
 
 **Repository**: A type of Service that represents a collection of data within a
-DataSource. For more information, see [Repositories](Repositories.md).
+DataSource. For more information, see [Repositories](Repository.md).

docs/site/Implementing-features.shelved.md

@@ -332,7 +332,7 @@ Welcome to `@loopback/repository`, a TypeScript facade for the
     }
     ```
 
-See [Repositories](Repositories.md) for more details on this topic.
+See [Repositories](Repository.md) for more details on this topic.
 
 ### Update test helpers and the controller use real model and repository
 

docs/site/Middleware.md

@@ -55,7 +55,7 @@ Injection, as well as Extension Point and Extensions.
     - As middleware in the sequence to handle all requests/responses
     - As global or local interceptors around controller method invocations
 
-- Build on top of the [Interceptors](Interceptors.md) infrastructure. We have
+- Build on top of the [Interceptors](Interceptor.md) infrastructure. We have
   used interceptors within the `InvokeMethod` action of a sequence. Expanding
   such capability to other actions is a natural choice. We're not reinventing
   the wheel as we are just extending the interceptor idea to new use cases.The
@@ -126,7 +126,7 @@ LoopBack's architecture.
    injection of middleware configurations.
 
 To harvest the best of breeds of both frameworks, we build the integration on
-top of the [interceptor](Interceptors.md) with community input as illustrated in
+top of the [interceptor](Interceptor.md) with community input as illustrated in
 the diagram below:
 
 ![middleware](imgs/middleware.png)

docs/site/Parsing-requests.md

@@ -44,7 +44,7 @@ example above, the first parameter is from source `path`, so its value will be
 parsed from a request's path.
 
 {% include note.html title="Controller documentation" content="
-See [controllers](Controllers.md) for more details of defining an endpoint.
+See [controllers](Controller.md) for more details of defining an endpoint.
 " %}
 
 {% include note.html title="OpenAPI operation object" content="

docs/site/REST-action-sequence.md

@@ -556,8 +556,8 @@ In Express, a route handler is a middleware function that serves the response
 and does not call `next()`. Handlers can be registered using APIs like
 `app.get()`, `app.post()`, but also a more generic `app.use()`.
 
-In LoopBack, we typically use [Controllers](Controllers.md) and
-[Route handlers](Routes.md) to implement request handling logic.
+In LoopBack, we typically use [Controllers](Controller.md) and
+[Route handlers](Route.md) to implement request handling logic.
 
 To support interoperability with Express, it is also possible to take an Express
 Router instance and add it to a LoopBack application as an external router - see

docs/site/REST-middleware-sequence.md

@@ -945,8 +945,8 @@ In Express, a route handler is a middleware function that serves the response
 and does not call `next()`. Handlers can be registered using APIs like
 `app.get()`, `app.post()`, but also a more generic `app.use()`.
 
-In LoopBack, we typically use [Controllers](Controllers.md) and
-[Route handlers](Routes.md) to implement request handling logic.
+In LoopBack, we typically use [Controllers](Controller.md) and
+[Route handlers](Route.md) to implement request handling logic.
 
 To support interoperability with Express, it is also possible to take an Express
 Router instance and add it to a LoopBack application as an external router - see

docs/site/Relations.md

@@ -30,7 +30,7 @@ Model relation in LoopBack 3 is one of its powerful features which helps users
 define real-world mappings between their models, access sensible CRUD APIs for
 each of the models, and add querying and filtering capabilities for the relation
 APIs after scaffolding their LoopBack applications. In LoopBack 4, with the
-introduction of [repositories](Repositories.md), we aim to simplify the approach
+introduction of [repositories](Repository.md), we aim to simplify the approach
 to relations by creating constrained repositories. This means that certain
 constraints need to be honoured by the target model repository based on the
 relation definition, and thus we produce a constrained version of it as a

docs/site/Repository-generator.md

@@ -12,8 +12,8 @@ permalink: /doc/en/lb4/Repository-generator.html
 ### Synopsis
 
 Adds a new
-[Repository class (or multiple backed by the same datasource)](Repositories.md)
-to a LoopBack application with one single command.
+[Repository class (or multiple backed by the same datasource)](Repository.md) to
+a LoopBack application with one single command.
 
 ```sh
 lb4 repository [options] [<name>]

docs/site/Route.md

@@ -20,7 +20,7 @@ package.
 
 Operations are functions that accept Parameters. They can be implemented as
 plain JavaScript/TypeScript functions (like http handler functions) or as
-methods in [Controllers](Controllers.md).
+methods in [Controllers](Controller.md).
 
 ```ts
 // greet is a basic operation

docs/site/Server.md

@@ -313,7 +313,7 @@ constructor(options: ApplicationConfig = {}) {
 }
 ```
 
-If you contribute the enhancer from a [component](Components.md), create the
+If you contribute the enhancer from a [component](Component.md), create the
 binding in this way:
 
 ```ts

docs/site/Testing-your-application.md

@@ -366,9 +366,9 @@ which breaks the recommended test layout 'arrange-act-assert' (or
 #### Create a stub Repository
 
 When writing an application that accesses data in a database, the best practice
-is to use [repositories](Repositories.md) to encapsulate all
+is to use [repositories](Repository.md) to encapsulate all
 data-access/persistence-related code. Other parts of the application (typically
-[controllers](Controllers.md)) can then depend on these repositories for data
+[controllers](Controller.md)) can then depend on these repositories for data
 access. To test Repository dependents (for example, Controllers) in isolation,
 we need to provide a test double, usually as a test stub.
 

docs/site/Validation-controller-layer.md

@@ -30,7 +30,7 @@ return this.coffeeShopRepository.create(coffeeShop);
 
 ## Add interceptor for validation
 
-Another way is to use [interceptors](Interceptors.md).
+Another way is to use [interceptors](Interceptor.md).
 
 Interceptors are reusable functions to provide aspect-oriented logic around
 method invocations.

docs/site/Working-with-data.md

@@ -9,7 +9,7 @@ permalink: /doc/en/lb4/Working-with-data.html
 In LoopBack 4, models describe the shape of data, repositories provide behavior
 like CRUD operations, and controllers define routes (this is different from
 LoopBack 3.x where models implement behavior too). LB4
-[repositories](Repositories.md) provide a couple of create, read, update, and
+[repositories](Repository.md) provide a couple of create, read, update, and
 delete (CRUD) operations. Once you have defined these three artifacts, you can
 add data to the model, manipulate the data, and query it through these CRUD
 operations. The following is an overview of CRUD operations at different levels:

docs/site/express-with-lb4-rest-tutorial.md

@@ -22,9 +22,9 @@ application on a LoopBack 4 application, see
 " %}
 
 This tutorial assumes familiarity with scaffolding a LoopBack 4 application,
-[`Models`](Model.md), [`DataSources`](DataSources.md),
-[`Repositories`](Repositories.md), and [`Controllers`](Controllers.md). To see
-how they're used in a LoopBack application, please see the
+[`Models`](Model.md), [`DataSources`](DataSource.md),
+[`Repositories`](Repository.md), and [`Controllers`](Controller.md). To see how
+they're used in a LoopBack application, please see the
 [`Todo` tutorial](todo-tutorial.md).
 
 ## Try it out