Fix broken links

spikeheap · spikeheap · commit 51cde5c13066 · 2024-10-21T15:46:46.000+01:00
diff --git a/docs/api-playbook/04-Governance/API Documentation/swagger_documentation.md b/docs/api-playbook/04-Governance/API Documentation/swagger_documentation.md
@@ -60,7 +60,7 @@ Providing a mock API and API blueprints will remove this blocker as it will give
 
 ## SwaggerHub Standards:
 
-We utilise two of SwaggerHub's functions to document the status of our APIs: **tagging API environments** and **publishing API specifications**. These allow us to track whether an API is active and what environments it is available in. These also automatically sync with our [Developer Hub](https://developer-api.hackney.gov.uk/). To see more about the Developer Hub, please refer to the [relevant page](/developer_hub).
+We utilise two of SwaggerHub's functions to document the status of our APIs: **tagging API environments** and **publishing API specifications**. These allow us to track whether an API is active and what environments it is available in. These also automatically sync with our [Developer Hub](https://developer-api.hackney.gov.uk/). To see more about the Developer Hub, please refer to the [relevant page](../../developer_hub).
 
 ### Tagging API Environments:
 
diff --git a/docs/api-playbook/04-Governance/developer_onboarding.md b/docs/api-playbook/04-Governance/developer_onboarding.md
@@ -7,7 +7,7 @@ sidebar_position: 2
 ### Proposing changes
 We love innovation and are always open to learning, iterating and improving. To suggest improvements and changes to our existing standards and tech stack, please use our technical architecture, frontend and data communities of practice.
 
-- Our preferred BE stack is documented [here](/preferred_tech_stack.md).
+- Our preferred BE stack is documented [here](../../Development%20Lifecycle/How%20to%20build%20an%20API/Preferred%20tech%20stack/).
 
 ### Reusable components catalogue
 Before you commence the development of a new API, micro-frontend or NuGet shared package, please refer to our [Developer Hub](https://developer-api.hackney.gov.uk/), where you can find information about available reusable components and APIs available for reuse.
@@ -18,19 +18,19 @@ Before you commence the development of a new API, micro-frontend or NuGet shared
 All technical members of a project team must familiarise themselves with [Hackney’s development standards](https://playbook.hackney.gov.uk/ways-of-working/), which follow the Twelve Factor Application methodology. Those define the high level principles to follow when developing a digital product.
 Playbooks
 
-#### What are they? 
+#### What are they?
 
 At Hackney, we use playbooks to define the standards and approaches to use when building front end and back end services. The playbooks include specific information about the architecture, technology and practices that all services must follow in order to be compliant for any service development. They are intended for easy developer onboarding and provide all information required for reusable and consistent product development.
 
-#### What do we use them for? 
+#### What do we use them for?
 
 We use playbooks to provide guidance of the standards and ways to implement to ensure we are building compliant products. The standards are in place in order to help us achieve our aim of delivering reusable, consistent, resilient, scalable and secure services. Ultimately, our goal is to provide our residents with better and uniform experience through more performant and reliable applications, increased speed of development and good future maintainability so we can support our digital services even when project team members move on.
 
-#### Technical assessments: 
+#### Technical assessments:
 
 Hackney’s playbooks reflect the standards and quality of technical implementation that digital services should follow and will be assessed against to be accepted into service. We do understand that sometimes there are use cases, which will require a different approach and we are always open to suggestions for improvements. Any deviations or proposals for changes must be documented in the form of an Architecture Decision Record ( ADR ) and presented at a community of practice to promote collaboration and consistency.
 API and Backend services Playbook
-https://playbook.hackney.gov.uk/API-Playbook/ 
+https://playbook.hackney.gov.uk/API-Playbook/
 
 You can find information about:
 - API and Listeners Boilerplate
@@ -45,7 +45,7 @@ You can find information about:
 - Security practices for APIs
 
 ### Micro frontends (MFE) Playbook
-https://playbook.hackney.gov.uk/micro-frontends/ 
+https://playbook.hackney.gov.uk/micro-frontends/
 
 You can find information about:
 - MFE cli and boilerplate
@@ -58,7 +58,7 @@ You can find information about:
 
 #### Technical architecture
 
-**When?** Every Wednesday, 16:00-17:00. 
+**When?** Every Wednesday, 16:00-17:00.
 
 **What is it?** A platform to discuss proposals for changes to technical and architectural approaches and tooling, as well as a place to suggest new technical implementations.
 
@@ -81,14 +81,15 @@ You can find information about:
 
 **When?** Every Thursday, 15:00 - 16:00.
 
-**What is it?** A platform to discuss frontend specific tooling and approaches, micro-frontend architecture and reusability and suggestions for changes. 
+**What is it?** A platform to discuss frontend specific tooling and approaches, micro-frontend architecture and reusability and suggestions for changes.
 
 **How can I make use of it?** Please join the #frontend slack channel and drop a message there with a topic you wish to discuss at the meetup. The meetup is open to everyone so feel free to forward the calendar invitation to anyone who might be interested.
 
 ### Preferred technical stack
-Our preferred technical stack for API and backend services (e.g. Listeners) implementation can be found [here](/preferred_tech_stack.md).
+Our preferred technical stack for API and backend services (e.g. Listeners) implementation can be found [here](- Our preferred BE stack is documented [here](../../Development%20Lifecycle/How%20to%20build%20an%20API/Preferred%20tech%20stack/).
+).
 
-To achieve consistency and future maintainability, it’s important to build services following the preferred tech stack. If a use case requires a different approach, please discuss that with one of the Senior Engineers for awareness. 
+To achieve consistency and future maintainability, it’s important to build services following the preferred tech stack. If a use case requires a different approach, please discuss that with one of the Senior Engineers for awareness.
 
 To set up your developer workstation, please refer to the Workstation Setup Guide [here](https://docs.google.com/document/d/1PaID4hmDJPzW2onOaKytVL3qrTB_HyYW3_EWyRmWC48/edit?usp=sharing)
 
@@ -105,13 +106,13 @@ All APIs must be built in a reusable manner, unless they implement a very specif
 We use [SwaggerHub](https://app.swaggerhub.com/organizations/Hackney) to document our APIs and their respective data contracts. All new and existing APIs must have corresponding SwaggerHub documentation. It is the responsibility of the engineers who amend existing APIs to also update the documentation so it is kept up-to-date.
 - If you or your team is building new APIs or making changes to existing API endpoints, please request SwaggerHub access so you can amend the specifications documented to ensure they are always up-to-date.
 
-In addition, we also have [API specifications](https://playbook.hackney.gov.uk/api-specifications/), which capture a summary of the user needs and any other findings related to an API. 
-- A new API specification must be produced for all new APIs. 
+In addition, we also have [API specifications](https://playbook.hackney.gov.uk/api-specifications/), which capture a summary of the user needs and any other findings related to an API.
+- A new API specification must be produced for all new APIs.
 - The API specification document should link off to the SwaggerHub page that outlines the API contract.
 - The API specification should be updated when the API introduces new endpoints or changes to existing functionality.
 
 ### Software development DevOps practices
-Our DevOps practices followed as part of the Software Development Lifecycle are documented [here](/deployment_pipeline.md).
+Our DevOps practices followed as part of the Software Development Lifecycle are documented [here](../../DevOps%20practices/deployment_pipeline/).
 
 You will find information about:
 - Branching strategies
@@ -125,7 +126,7 @@ You will find information about:
 [Production deployment - Live service infrastructure requirement](https://docs.google.com/document/d/1UrT6u4j8AlyPf-aD_E4c30uH27MJgIJoVxYR9kKGzFw/edit)
 
 ### APIs
-To assess the API compliance prior to deploying it, please refer to [APIs compliance checklist](/docs/api_compliance.md).
+To assess the API compliance prior to deploying it, please refer to [APIs compliance checklist](../api_compliance).
 
 ### Asking a question
 For any questions and suggestions regarding our tech stack, tools, processes and practices, please contact us via:
diff --git a/docs/api-playbook/05-Development Lifecycle/01-Designing your API/http.md b/docs/api-playbook/05-Development Lifecycle/01-Designing your API/http.md
@@ -218,7 +218,7 @@ Below we list the most commonly used and best understood HTTP status codes, cons
 | 405  | Method Not Allowed - the method is not supported                                                                                                 | All                      |
 | 406  | Not Acceptable - resource can only generate content not acceptable according to the Accept headers sent in the request                                        | All                      |
 | 415  | Unsupported Media Type - e.g. clients sends request body without content type                                                                                 | POST, PUT, DELETE, PATCH |
-| 429  | Too many requests - the client does not consider rate limiting and sent too many requests. See [MUST Use Code 429 with Headers for Rate Limits](#153).      | All                      |
+| 429  | Too many requests - the client does not consider rate limiting and sent too many requests.      | All                      |
 
 ### Server Side Error Codes:
 
diff --git a/docs/api-playbook/05-Development Lifecycle/02-How to build an API/01-Preferred tech stack/Readme.md b/docs/api-playbook/05-Development Lifecycle/02-How to build an API/01-Preferred tech stack/Readme.md
@@ -5,16 +5,17 @@
 - .NET Core 3.1 (C#);
 - AWS Lambda;
 - Serverless framework.
-  * [See more](/serverless_lambda);
+  * [See more](./serverless_lambda);
 - AWS API Gateway;
 - Hackney Lambda authoriser (for authentication).
-  * [See more](/lambda_authoriser);
+  * [See more](../API-Practices and tools/lambda_authoriser);
 - FxCop for static code analysis.
-  * [See more](/static_code_analysis);
+  * [See more](./static_code_analysis);
 - dotnet-format for linting.
-  * [See more](/linting);
+  - [See more](../API-Practices and tools/linting);
 - AWS Canaries for availability monitoring.
-  * [See more](/uptime_monitoring);
+  * [See more](../../../DevOps%20practices/Monitoring/uptime_monitoring);
+
 ## Testing:
 
 - [nUnit](https://nunit.org/);
@@ -28,20 +29,20 @@
     * For spinning up DB image containers and running tests against that database ;
     * _During local development and during test run as part of CI/CD_;
 
-*For more guidance on testing, go to the [testing](/tdd) section*.
+*For more guidance on testing, go to the [testing](../../../Testing/tdd) section*.
 
 ## Common:
 
 - Swagger documentation.
   * For API design prior to implementation;
   * Automated Swagger docs for each API endpoint deployed;
-  * [See more](/documentation);
+  * [See more](../../API Documentation/swagger_documentation);
 - CircleCI for CI/CD.
-  * [See more](/deployment_pipeline);
+  * [See more](../../../DevOps%20practices/deployment_pipeline);
 - GitHub for version control.
   * [HackIT Github](https://github.com/LBHackney-IT);
 - AWS for cloud hosting;
 - AWS CloudWatch for monitoring;
 - Terraform for Infrastructure as Code (IaC) (e.g. setting up AWS DMS).
-  * [See more](/infrastructure);
+  - [See more](../../../DevOps%20practices/infrastructure);
 - AWS Parameter Store for secrets (connection string and similar);
diff --git a/docs/api-playbook/05-Development Lifecycle/03-Implementing HTTP endpoints/GET endpoint/get_dynamodb.md b/docs/api-playbook/05-Development Lifecycle/03-Implementing HTTP endpoints/GET endpoint/get_dynamodb.md
@@ -9,7 +9,7 @@ GET requests are used to **read** either a single or a collection resource.
 
   - GET requests must NOT have a request body payload;
 
-**Note:** GET requests on collection resources should provide sufficient filter and [pagination](pagination.md) mechanisms;
+**Note:** GET requests on collection resources should provide sufficient filter and [pagination](../../../Designing%20your%20API/pagination) mechanisms;
 
 [Here is an example PR to show how to build an GET endpoint using DynamoDB](https://github.com/LBHackney-IT/notes-api/pull/8/files)
 
diff --git a/docs/api-playbook/05-Development Lifecycle/03-Implementing HTTP endpoints/GET endpoint/get_opensearch.md b/docs/api-playbook/05-Development Lifecycle/03-Implementing HTTP endpoints/GET endpoint/get_opensearch.md
@@ -10,7 +10,7 @@ GET requests are used to **read** either a single or a collection resource.
 
   - GET requests must NOT have a request body payload;
 
-**Note:** GET requests on collection resources should provide sufficient filter and [pagination](pagination.md) mechanisms;
+**Note:** GET requests on collection resources should provide sufficient filter and [pagination](../../../Designing%20your%20API/pagination) mechanisms;
 
 [Here is an example PR to show how to build a search endpoint using OpenSearch (Also known as ElasticSearch)](https://github.com/LBHackney-IT/housing-search-api/pull/154)
 
diff --git a/docs/api-playbook/05-Development Lifecycle/03-Implementing HTTP endpoints/GET endpoint/get_postgres.md b/docs/api-playbook/05-Development Lifecycle/03-Implementing HTTP endpoints/GET endpoint/get_postgres.md
@@ -9,7 +9,7 @@ GET requests are used to **read** either a single or a collection resource.
 
   - GET requests must NOT have a request body payload;
 
-**Note:** GET requests on collection resources should provide sufficient filter and [pagination](pagination.md) mechanisms;
+**Note:** GET requests on collection resources should provide sufficient filter and [pagination](../../../Designing%20your%20API/pagination) mechanisms;
 
 We have created a video that gives developers a good understanding of how we build API Endpoints using Postgres from beginning to end, following best practices.
 
diff --git a/docs/api-playbook/05-Development Lifecycle/04-Listeners/listener_intro.md b/docs/api-playbook/05-Development Lifecycle/04-Listeners/listener_intro.md
@@ -2,7 +2,7 @@
 
 ## Introduction
 
-[Events](/serverless_lambda#events) occur all the time throughout any application, they may for example be a database or file being updated, a timer firing or a message being sent,
+[Events](../../How%20to%20build%20an%20API/Preferred%20tech%20stack/serverless_lambda#events) occur all the time throughout any application, they may for example be a database or file being updated, a timer firing or a message being sent,
 and sometimes additional processing is required elsewhere in the system as a result of them happening.
 
 These events can be used to trigger AWS Lambda functions to perform the necessary processing.
diff --git a/docs/api-playbook/05-Development Lifecycle/04-Listeners/listener_tech_stack.md b/docs/api-playbook/05-Development Lifecycle/04-Listeners/listener_tech_stack.md
@@ -8,13 +8,13 @@ title: Listener Tech Stack
 - .NET Core 3.1 (C#);
 - AWS Lambda;
 - Serverless framework.
-  - [See more](../02-How%20to%20build%20an%20API/01-Preferred%20tech%20stack/serverless_lambda.md);
+  - [See more](../../How%20to%20build%20an%20API/Preferred%20tech%20stack/serverless_lambda);
 - FxCop for static code analysis.
-  * [See more](../02-How%20to%20build%20an%20API/01-Preferred%20tech%20stack/static_code_analysis.md);
+  * [See more](../../How%20to%20build%20an%20API/Preferred%20tech%20stack/static_code_analysis/);
 - [Hackney.Core.xxx](https://github.com/LBHackney-IT/lbh-core).
   * Common Hackney NuGet packages providing common functionality;
 - dotnet-format for linting.
-  * [See more](../../05-Development%20Lifecycle/06-API%20Practices%20and%20tools/linting.md);
+  * [See more](../../API%20Practices%20and%20tools/linting/);
 
 ## Testing:
 
@@ -30,16 +30,16 @@ title: Listener Tech Stack
     * For spinning up DB image containers and running tests against that database.;
     * _During local development and during test run as part of CI/CD_;
 
-*For more guidance on testing, go to the [testing](/tdd) section*
+_For more guidance on testing, go to the [testing](../../../Testing/tdd) section_
 
 ## Common:
 
 - CircleCI for CI/CD.
-  * [See more](/deployment_pipeline);
+  - [See more](../../../DevOps%20practices/deployment_pipeline/);
 - GitHub for version control.
   * [HackIT Github](https://github.com/LBHackney-IT);
 - AWS for cloud hosting;
 - AWS CloudWatch for monitoring;
 - Terraform for Infrastructure as Code (IaC) (e.g. setting up AWS DMS).
-  * [See more](/infrastructure);
+  - [See more](../../../DevOps%20practices/infrastructure);
 - AWS Parameter Store for secrets (connection string and similar);
diff --git a/docs/api-playbook/06-Testing/tdd.md b/docs/api-playbook/06-Testing/tdd.md
@@ -27,7 +27,7 @@ _A better test name that describes what is being tested_
 ### Unit Tests:
 
 Unit tests should provide good coverage of the various scenarios that may be encountered; from the main success scenario to any exceptionals or edge cases.
-[See More](/unit_testing)
+[See More](../unit_testing)
 ### Red-Green-Refactor-Commit:
 
 - **Red**
diff --git a/docs/api-playbook/07-DevOps practices/Monitoring/alerting.md b/docs/api-playbook/07-DevOps practices/Monitoring/alerting.md
@@ -44,7 +44,7 @@ We use AWS CloudWatch Canaries to monitor the availability of our APIs and front
 
 - The current creation process for a canary is **manual**;
 
-[See the guidance for Canaries here](/uptime_monitoring)
+[See the guidance for Canaries here](../uptime_monitoring)
 
 ### AWS Canaries for front end applications:
 
diff --git a/docs/api-playbook/07-DevOps practices/aws_ecs.md b/docs/api-playbook/07-DevOps practices/aws_ecs.md
@@ -41,7 +41,7 @@ This means that if any large file needs to be stored at run time to be accessed
 
 It is recommended that you use Terraform to provision AWS resources. We already have produced a terraform template that generates all necessary resources for an API/app that is to be hosted using ECS with Fargate.
 
-In this playbook, please refer to the [Terraform section](/infrastructure) to find out more about the templates and how to use them. The template has configuration both for front end apps and for back end services that are to use ECS with Fargate.
+In this playbook, please refer to the [Terraform section](../infrastructure) to find out more about the templates and how to use them. The template has configuration both for front end apps and for back end services that are to use ECS with Fargate.
 
 ** The Terraform template creates the following resources: **
 
diff --git a/docs/api-playbook/07-DevOps practices/deployment_pipeline.md b/docs/api-playbook/07-DevOps practices/deployment_pipeline.md
@@ -37,7 +37,7 @@ We use the Test-Driven Development (TDD) approach when writing code.
 
 Each project’s test suite must include units tests produced as part of TDD as well as integration tests.
 
-** More on practices in Hackney for writing tests here: [TDD Practices](/tdd) **
+** More on practices in Hackney for writing tests here: [TDD Practices](../../Testing/tdd) **
 ## Environments:
 
 ### Development:
diff --git a/docs/api-playbook/07-DevOps practices/lambda_best_practices.md b/docs/api-playbook/07-DevOps practices/lambda_best_practices.md
@@ -71,7 +71,7 @@ example-api’s serverless configuration includes the basic setup for policies r
 
 In some cases it’s useful to have a bit more insight on how the Lambda is performing. In that case services like X-Ray can be implemented. They require some additional configuration to the application, but are generally relatively easy to implement at any point.
 
-[**More about X-Ray here**](/x_ray)
+[**More about X-Ray here**](../Monitoring/x_ray)
 ### Alerts:
 
-For more details on logging and alerts in general, please see our [alerting guide](/alerting).
+For more details on logging and alerts in general, please see our [alerting guide](../Monitoring/alerting).
diff --git a/docs/api-playbook/09-Support/creating_support_doc.md b/docs/api-playbook/09-Support/creating_support_doc.md
@@ -13,7 +13,6 @@ To create support documentation that is easy to find and becomes quickly availab
 - Create a new branch in the API playbook GitHub repository.
 - Create a new file in the ‘docs’ folder of the repository.
 - Copy the template into the new file and fill in the information for each section described.
-    - The template can be found [here](./support-issue-template.md).
 - Add the following to the top of the document to make it discoverable by the sidebar module
 ```
     ---
diff --git a/docs/api-playbook/10-Other useful information/debugging_apis.md b/docs/api-playbook/10-Other useful information/debugging_apis.md
@@ -52,7 +52,7 @@
 ## Configuration and security:
 
 1. Make sure slow query logging is enabled on any relevant RDS database instances by [steps to check or add to Terraform config?]
-2. See the [Production Testing Checklist](/production_testing) to complete this section!
+2. See the [Production Testing Checklist](../../Testing/production_checklist) to complete this section!
 
 ## Errors:
-1. See the [Production Testing Checklist](../06-Testing/production_checklist.md) to complete this section!
+1. See the [Production Testing Checklist](../../Testing/production_checklist) to complete this section!
diff --git a/docs/api-playbook/11-faqs.md b/docs/api-playbook/11-faqs.md
diff --git a/docs/architecture-pillars/1-Reliability/automated_remediation.md b/docs/architecture-pillars/1-Reliability/automated_remediation.md
diff --git a/docs/architecture-pillars/1-Reliability/production_deployment.md b/docs/architecture-pillars/1-Reliability/production_deployment.md
diff --git a/docs/architecture-pillars/7-Development practices/data_driven_guidelines.md b/docs/architecture-pillars/7-Development practices/data_driven_guidelines.md
diff --git a/docs/architecture-pillars/7-Development practices/developer_onboarding.md b/docs/architecture-pillars/7-Development practices/developer_onboarding.md
diff --git a/docs/product-playbook/How we work/README.md b/docs/product-playbook/How we work/README.md
