Add URL encoding for spaces in all .md documents

Author: emanguy

practices/development/examples/go-microservice-monorepo/doc/Authentication.md

@@ -10,7 +10,7 @@ request, but doesn't otherwise enforce use of credentials when hitting the API.
 The `auth` package provides a JWT extractor function to retrieve the claims parsed by the authentication middleware.
 This function is called `auth.RetrieveKeycloakClaims()`, and because the authentication token may not always be present,
 it returns a boolean in addition to the returned data structure stating whether the token is present or not. It is recommended
-that you respond with a 401 Unauthorized if you expect the token to be present. See the [microservice architecture docs](Microservice Architecture.md#writing-rest-controllers-driving-adapters)
+that you respond with a 401 Unauthorized if you expect the token to be present. See the [microservice architecture docs](Microservice%20Architecture.md#writing-rest-controllers-driving-adapters)
 for information on writing REST controllers.
 
 Here's an example of using `auth.RetrieveKeycloakClaims()`:

practices/development/examples/go-microservice-monorepo/doc/Configuration.md

@@ -55,7 +55,7 @@ If those checks do not pass, construction of the registry fails with an error de
 
 Configuration options are created with the `config.NewOption()` function. It takes two parameters - the name of the configuration option
 in the environment and whether the option should be required or not. These options are defined in the **options** package if
-they're specific to a certain microservice or **sharedoptions** if the option is shared across multiple microservices. See [the repository layout docs](Navigation and Repository Layout.md)
+they're specific to a certain microservice or **sharedoptions** if the option is shared across multiple microservices. See [the repository layout docs](Navigation%20and%20Repository%20Layout.md)
 for information on where those are. These options can also be documented, so one can see what a configuration option is for when
 retrieved from a registry.
 
@@ -72,7 +72,7 @@ var TheAdditionalTopping = config.NewOption("ADDITIONAL_TOPPING", false)
 ### Creating a validated configuration option
 
 Configuration options can also use `jellydator/validation` validators to validate the content of configuration options. See
-the [validation documentation](Microservice Architecture.md#dtos-validation-and-responding) for more information on validation.
+the [validation documentation](Microservice%20Architecture.md#dtos-validation-and-responding) for more information on validation.
 These validations are run during the construction of the configuration registry to verify everything is in the correct format.
 Validations only run if the option is present, in the case of optional validation options.
 To create a validated configuration option, you can either construct it via the alternate constructor `config.NewValidatedOption()`
@@ -91,7 +91,7 @@ var ShortConfigOption = config.NewValidatedOption("SHORT_CONFIG_OPTION", false,
 ### Creating a configuration registry and registering options
 
 Configuration options are registered with a configuration registry via a `config.RegistryBuilder` which should be defined in
-a microservice's **options** package. See the [repository layout docs](Navigation and Repository Layout.md) for where that is.
+a microservice's **options** package. See the [repository layout docs](Navigation%20and%20Repository%20Layout.md) for where that is.
 Once all the options are added, the `RegistryBuilder.VerifyAndBuild()` function is invoked which verifies the configuration in the
 environment and constructs the registry.
 

practices/development/examples/go-microservice-monorepo/doc/Logging.md

@@ -45,13 +45,13 @@ configuration, the "production" state is determined by the `sharedoptions.IsInPr
 simple constructor parameter. 
 
 See ["Instantiating the logger"](#instantiating-the-logger) for more information on constructing the
-logger, and [the repository layout docs](Navigation and Repository Layout.md#layout-of-the-common-library) 
+logger, and [the repository layout docs](Navigation%20and%20Repository Layout.md#layout-of-the-common-library) 
 for more information on shared configuration options.
 
 ## Adjusting the log level
 
 Log level filters are controlled by both the shared option `sharedoptions.LogLevel` and the shared log level controller defined in the `loglevel` shared feature.
-See [the repository layout docs](Navigation and Repository Layout.md) for where to find those packages in the repo.
+See [the repository layout docs](Navigation%20and%20Repository Layout.md) for where to find those packages in the repo.
 
 The `loglevel` shared feature exposes HTTP endpoints for live-updating the application log level in production without an application restart.
 
@@ -105,4 +105,4 @@ initializationErr := logger.InitLoggerFromConfig(*options.Registry)
 if initializationErr != nil {
 	fmt.Println("Initializing the logger failed!")
 }
-```
+```

practices/development/examples/go-microservice-monorepo/doc/Microservice Architecture.md

@@ -153,7 +153,7 @@ func (CoreLogic) GroupSize(ctx context.Context, totalThings, numGroups int, calc
 ## Writing REST controllers (driving adapters)
 
 REST controllers are driving adapters that connect to the business logic's driving ports. They implement the `router.Controller`
-interface (see [repository layout](Navigation and Repository Layout.md) for where that package is) so they can be
+interface (see [repository layout](Navigation%20and%20Repository%20Layout.md) for where that package is) so they can be
 attached to a `router.Router` instance. They invoke business logic and convert DTO (Data Transfer Object) types to domain types defined in the
 business logic by the business logic's driven port definition.
 
@@ -399,7 +399,7 @@ func MyResponseFromDomain(stringSlice []string) MyCoolResponse {
 
 In order to make error responses consistent across the application and reduce the amount of boilerplate necessary, several
 error response functions are available to quickly respond with different HTTP status codes and report an error. These
-error response functions are available in the `response` package (see [repository layout](Navigation and Repository Layout.md)
+error response functions are available in the `response` package (see [repository layout](Navigation%20and%20Repository%20Layout.md)
 for where that is).
 
 The `response.APIErrorHelper` type returned from the canned response functions can be customized after its construction
@@ -485,7 +485,7 @@ wrapping any inserts triggered by driven ports will be automatically rolled back
 ### Attaching controllers to the router
 
 REST controllers implementing the `router.Controller` interface can be attached to the `router.Router` instance via the
-`router.Router.AttachControllers()` function. Each controller is instantiated in its own function in `bootstrap.go` (see [repo layout docs](Navigation and Repository Layout.md))
+`router.Router.AttachControllers()` function. Each controller is instantiated in its own function in `bootstrap.go` (see [repo layout docs](Navigation%20and%20Repository%20Layout.md))
 and added to the slice of controllers, which is passed along to the `AttachControllers()` function. Here's a small example,
 using the sample controller as seen in the previous examples:
 
@@ -545,7 +545,7 @@ func (DatabaseAdapter) GetSomeData(ctx context.Context) (int, error) {
 ```
 
 The database connection is attached to the context via the database context middleware, as described in [the middleware docs](Middleware.md#database-connection-middleware).
-You can see all the querying options available on the `database.Connection` type (see the [repo layout](Navigation and Repository Layout.md)
+You can see all the querying options available on the `database.Connection` type (see the [repo layout](Navigation%20and%20Repository%20Layout.md)
 for where the database package is).
 
 ### Database-specific DTOs
@@ -588,4 +588,4 @@ func (DatabaseAdapter) GetSomeData(ctx context.Context) (int, error) {
 
 ### Communicating with other systems over HTTP
 
-TBD, we can take care of this subsystem in another ticket. Needs to be done in a way that we can mock responses from external systems.
+TBD, we can take care of this subsystem in another ticket. Needs to be done in a way that we can mock responses from external systems.

practices/development/examples/go-microservice-monorepo/doc/Middleware.md

@@ -20,7 +20,7 @@ The database connection middleware holds a `sqlx.DB` database connection and att
 This way, database-based driven ports can extract the database connection from the request context which is passed through
 every layer.
 
-See [this section in the microservice architecture docs](Microservice Architecture.md#acquiring-a-database-connection)
+See [this section in the microservice architecture docs](Microservice%20Architecture.md#acquiring-a-database-connection)
 for more information on accessing the database connection.
 
 ## Logging middleware

practices/development/examples/go-microservice-monorepo/doc/Navigation and Repository Layout.md

@@ -11,16 +11,16 @@ layout, making it easy to find different parts of the API/business logic/etc.
   * **auth** - Contains code for extracting authentication information from incoming requests, as well as data structures representing the contents of authentication information. For more info, see [Authentication.md](./Authentication.md).
   * **config** - Contains code for defining configuration options and retrieving them from a configuration registry. For more information see [Configuration.md](./Configuration.md)
     * **sharedoptions** - Contains common configuration options that may be used by all microservices
-  * **database** - Contains database-related code, including functions for managing transactions and extracting the database connection from the current request context. Relevant information can be found in [Middleware.md](./Middleware.md), [Microservice Architecture.md](./Microservice Architecture.md), and [Testing.md](./Testing.md).
+  * **database** - Contains database-related code, including functions for managing transactions and extracting the database connection from the current request context. Relevant information can be found in [Middleware.md](./Middleware.md), [Microservice Architecture.md](./Microservice%20Architecture.md), and [Testing.md](./Testing.md).
   * **logger** - Contains the global logger instance and functions for initializing it. For more information, see [Logging.md](./Logging.md).
-  * **request** - Contains utilities for extracting information from requests, such as deserializing the request body or pulling out the request context. For more information, see [Microservice Architecture.md](./Microservice Architecture.md).
+  * **request** - Contains utilities for extracting information from requests, such as deserializing the request body or pulling out the request context. For more information, see [Microservice Architecture.md](./Microservice%20Architecture.md).
     * **testhelper** - Contains utilities for building HTTP requests in test code. See [Testing.md](./Testing.md) for more information.
-  * **response** - Contains utilities for generating a standard error structure on HTTP responses. For more information, see [Microservice Architecture.md](./Microservice Architecture.md).
+  * **response** - Contains utilities for generating a standard error structure on HTTP responses. For more information, see [Microservice Architecture.md](./Microservice%20Architecture.md).
       * **dtos** - Contains code for common DTO types used in HTTP responses
       * **testhelper** - Contains utilities for deserializing HTTP response bodies into data structures in tests. See [Testing.md](./Testing.md) for more information.
   * **types** - Contains useful types for representing things in your code such as nullable values.
   * **sharedfeatures** - Contains common software features and controllers that can be used across microservices
-    * **FEATURE NAME** - The name of the folder describes the microservice feature implemented by the business logic in this directory. See [Microservice Architecture.md](./Microservice Architecture.md) for more information.
+    * **FEATURE NAME** - The name of the folder describes the microservice feature implemented by the business logic in this directory. See [Microservice Architecture.md](./Microservice%20Architecture.md) for more information.
       * **controller** - Contains REST controller definitions and DTOs which use and drive the business logic
       * **adapter** - Contains external access adapters used by the business logic to access or send data in external systems, such as message queues or databases.
 
@@ -35,6 +35,6 @@ to package-level stuff.
   * **bootstrap.go** - Functions invoked by main.go to stand up the subsystems of the application, such as initializing the logger and connecting to the database. It also has functions for creating the HTTP router and attaching routes from all REST controllers in the app.
   * **options** - Contains the global configuration registry and initialization functions for it. See [Configuration.md](./Configuration.md) for more information.
   * **features** - Contains implementations for features that the microservice exposes
-    * **FEATURE NAME** - The name of the folder describes the microservice feature implemented by the business logic in this directory. See [Microservice Architecture.md](./Microservice Architecture.md) for more information.
+    * **FEATURE NAME** - The name of the folder describes the microservice feature implemented by the business logic in this directory. See [Microservice Architecture.md](./Microservice%20Architecture.md) for more information.
       * **controller** - Contains REST controller definitions which use and drive the business logic
       * **adapter** - Contains external access adapters used by the business logic to access or send data in external systems, such as message queues or databases

practices/development/examples/go-microservice-monorepo/doc/Rest API Conventions.md

@@ -70,7 +70,7 @@ Entries can be added to the collection by using the HTTP verb `POST`. `PUT` may
 (update if exists, otherwise insert) rather than an insertion into the collection. Requests made with these verbs
 contain the contents of the new entry in the request body.
 
-Fields in request bodies should be camel cased (via the go "json" struct tag, see [the microservice architecture docs](Microservice Architecture.md#dtos-validation-and-responding)
+Fields in request bodies should be camel cased (via the go "json" struct tag, see [the microservice architecture docs](Microservice%20Architecture.md#dtos-validation-and-responding)
 for more info) and acronyms should only capitalize the first letter.
 
 Examples: