[MB-9609] Migrate Backend Guides pages

docs/dev/contributing/backend/Push-Notifications-to-Prime.md → docs/api/docs/push-notifications-to-prime.md

@@ -1,3 +1,9 @@
+---
+sidebar_position: 2
+---
+
+# Push Notifications to Prime
+
 The push mechanism is a way to notify the Prime of changes as they happen. 
 
 We will be using Web Hooks to implement the push mechanism. 

docs/dev/contributing/backend/API-Errors.md → docs/api/guides/api-errors.md

@@ -1,4 +1,8 @@
-## API Errors
+---
+sidebar_position: 2
+---
+
+# API Errors
 
 Well formatted errors are an important component of education to the user of the API and should be given as much care as the API design. 
 
@@ -10,7 +14,7 @@ The JSON error body should provide a few things for the developer - a useful err
 
 The instance identifier enables the Milmove team to [look up Cloudwatch logs](How-to-Search-AWS-Cloudwatch-Logs-using-Instance-ID.md) that were written when the problem occurred. 
 
-### Default Error
+## Default Error
 The default JSON output representation for the error messages looks like: 
 
 	{   
@@ -20,7 +24,7 @@ The default JSON output representation for the error messages looks like:
 	}
 
 
-### Custom Error
+## Custom Error
 In addition to this default format, specific errors can choose to provide a custom representation that builds on this. A swagger example of how to define these errors is provided in this article on [backend errors](handle-backend-errors.md#defining-error-models-in-swagger).
 
 Validation errors for PUT, PATCH and POST requests need a field breakdown, and will return an `UnprocessableEntity` response. The top level detail can summarize or generalize the validation failures and provide the detailed errors in an additional `invalidFields` object, like so:
@@ -36,7 +40,7 @@ Validation errors for PUT, PATCH and POST requests need a field breakdown, and w
          }
      }
 
-### HTTP status codes
+## HTTP status codes
 
 HTTP defines a bunch of [meaningful status codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) that can be returned from an API. Milmove will leverage these to help the API consumers route their responses accordingly. 
 
@@ -76,7 +80,7 @@ An **error response** is a swagger generated type that we use to send errors bac
 mtoshipmentops.NewCreateMTOShipmentNotFound().WithPayload(payload)
 ```
 
-### Error types and Error responses
+## Error types and Error responses
 
 Error types in the code are defined in `pkg/apperror/errors.go`.
 
@@ -109,7 +113,7 @@ Here are the main error types and the responses we send in that case:
 
 Note: There might be new errors that we generate as the code evolves, but it's a good idea to understand these definitions and see if your error fits one of them before defining a new one. This improves consistency and makes the errors easier to understand and process by the user. If you do define a new error, please update this guide.
 
-### Security Guidelines
+## Security Guidelines
 
 In the next section we will cover converting the errors into responses. For each of the error responses, do not provide any information in the error message to help *debug* the issue. The target audience for the error responses is **the client, not the developer**. So we can let them know what they did wrong, but not reveal information about our own systems.
 
@@ -123,7 +127,7 @@ Secure logging of errors into Cloudwatch is what we use for developer informatio
 
 **Filepaths:** Equally there is no reason to reveal a file path to the client. Never provide this information in the error message.
 
-### Constructing Errors and Responses
+## Constructing Errors and Responses
 
 To create an instance of an error type, you'll call the `New` function for that error, and pass in parameters pertaining to that error.
 

docs/api/guides/api-programming-guide.md

@@ -0,0 +1,22 @@
+---
+sidebar_position: 1
+---
+
+# API Programming Guide
+
+This page will collect guides and information on programming our external facing APIs such as Prime API, Support API and Orders API.
+
+- [API Style Guide](api-style-guide)
+- [API Errors](api-errors)
+- [Guide to Creating an Endpoint](guide-to-creating-an-endpoint)
+- [How to Deprecate an API Endpoint](how-to-deprecate-endpoints)
+- [Acceptance Testing Prime API Endpoints](../testing/acceptance-testing-prime-api-endpoints)
+- [Push Notifications to Prime](../docs/push-notifications-to-prime)
+  - [[Acceptance Testing Notifications]]
+  - [[How to Add an Event Trigger]]
+
+## Using Postman
+
+- [Setting Up Postman](../../tools/postman/setting-up-postman)
+- [setup postman to make mutual tls api calls](../../tools/postman/setup-postman-to-make-mutual-tls-api-calls)
+- [Using Etags and the If Match Header in Postman](../../tools/postman/using-etags-and-the-if-match-header-in-postman)

docs/dev/contributing/backend/API-Style-Guide.md → docs/api/guides/api-style-guide.md

@@ -1,6 +1,12 @@
+---
+sidebar_position: 3
+---
+
+# API Style Guide
+
 We really need a comprehensive style guide, but in the meanwhile this page will collect useful bits of style related info.
 
-### Paths
+## Paths
 
 * Use kebab-case for all paths. This is a common convention.
 
@@ -13,9 +19,9 @@ We really need a comprehensive style guide, but in the meanwhile this page will
       '/mto-shipments/{mtoShipmentID}/addresses/{addressID}':
 
 
-### Parameters
+## Parameters
 
-#### **Case**
+### **Case**
 
 Consistency is important and using mixed cases is confusing. We selected camelCase because it's predominant in the code base and required the least amount of effort to implement. [[Decision Record]](https://github.com/transcom/mymove/blob/master/docs/adr/0044-params-styling.md)
 
@@ -32,7 +38,7 @@ Consistency is important and using mixed cases is confusing. We selected camelCa
       type: string
   ```
 
-#### **Special Parameters**
+### **Special Parameters**
 * All PUT and PATCH updates should have an eTag in the request. This is required to enforce optimistic locking. In the yaml, we mark these as `readOnly: true`.
 
 * All endpoints should properly populate the `produces` and `consumes` properties in the yaml. This is most usually set to `application/json`.
@@ -43,7 +49,7 @@ Consistency is important and using mixed cases is confusing. We selected camelCa
     produces:
       - application/json
   ```
-### Values
+## Values
 
 * Enum values should be ALL_CAPS with underscores. 
 
@@ -53,11 +59,11 @@ Consistency is important and using mixed cases is confusing. We selected camelCa
       - RECEIVING_AGENT
 ```
 
-### Tags
+## Tags
 
 * Use camelCase for the tags. Typically use object names for tags to group all endpoints associated with the object like `paymentRequest`.
 
-#### **Dates**
+### **Dates**
 
 * Use Swagger supported date formats, `date-time` or `date`, depending on whether we need to store an exact timestamp of the event. [[ADR]](https://github.com/transcom/mymove/blob/master/docs/adr/0051-swagger-date-formats.md)
 
@@ -79,15 +85,15 @@ Note that **in the database**, we use the following recommendations. [[Decision
 
 * Note that `updatedAt` and `createdAt` should always be marked `readOnly: true`. This is because we do not use any values the caller passes in, but instead calculate them ourselves.
 
-#### Convert dates to timestamps when comparing with timestamps
+### Convert dates to timestamps when comparing with timestamps
 
 1. Interpret a date in Pacific time to convert it to a naive timestamp
 
 2. Use beginning-of-day (12:00:00 am) or end-of-day (11:59:59 pm) depending on operation being performed. In general, use the most forgiving interpretation:
     * If you’re calculating if a date is more than 10 days in the future, use end-of-day.
     * If you’re calculating if a date is more than 2 days ago, use beginning-of-day.
 
-#### Serialization
+### Serialization
 
 Use [RFC3339](https://tools.ietf.org/html/rfc3339) unless you have a reason not to. It handles both dates and timestamps. `ISO8601` is roughly equivalent for the purposes of this document; however, it contains many optional features and it is recommended that projects move to `RFC3339` to avoid potential issues resulting from this complexity.
 

docs/dev/contributing/backend/Guide-to-Creating-an-Endpoint.md → docs/api/guides/guide-to-creating-an-endpoint.md

@@ -1,17 +1,21 @@
+---
+sidebar_position: 4
+---
+
 # Creating an Endpoint
 ###### These are the various steps that are involved in creating a new endpoint.
 
 Prior to creating an endpoint in the Handler folder, we must first add a new endpoint definition to swagger. We are using Swagger 2.0, which is [OpenAPI](https://swagger.io/specification/v2/), a specification we use to format our RESTful APIs and provide a template for us to communicate the information in our API.
 Always start with swagger. This step creates your endpoint definition and generates the files and helper functions you will need to create your endpoint. More specifically, swagger converts JSON user input into generated Go types.
 ## Adding  a new entry into the yaml
-All new definitions will be added in `mymove/swagger-def`. Note that we have broken down our spec into different files and we share definitions between files. 
-Built compiled versions of our API spec will be generated and stored in the swagger folder, which we will not edit directly. Notice that there is a yaml file for each of our APIs. 
-An endpoint definition for the prime will go into the Prime yaml, but you may notice there are some definitions in `mymove/swagger-def/definitions`. 
-This is because some definitions are shared across APIs and we've created a space to add those definitions in one place. 
+All new definitions will be added in `mymove/swagger-def`. Note that we have broken down our spec into different files and we share definitions between files.
+Built compiled versions of our API spec will be generated and stored in the swagger folder, which we will not edit directly. Notice that there is a yaml file for each of our APIs.
+An endpoint definition for the prime will go into the Prime yaml, but you may notice there are some definitions in `mymove/swagger-def/definitions`.
+This is because some definitions are shared across APIs and we've created a space to add those definitions in one place.
 For example, `Uploads.yaml` shares its definition across various APIs, and rather than creating various yaml files for this action, we have created one and added it to the shared `definitions` folder.
 
 For the purposes for adding a new endpoint, make sure that your endpoint is defined in these sections:
-* `tags` - is where we group all of our endpoints by category (i.e. shipment endpoints, agent endpoints, service item endpoints, etc.). 
+* `tags` - is where we group all of our endpoints by category (i.e. shipment endpoints, agent endpoints, service item endpoints, etc.).
          This top level field is where our gen files will divide the endpoints into their own packages. Tag component names are `camelCase`.
 * `paths` - defines our endpoint. Path names use `kebab-case`.
 * `definitions` - defines the shape of the data for our endpoint. Definitions component names are `PascalCase`.
@@ -21,7 +25,7 @@ For the purposes for adding a new endpoint, make sure that your endpoint is defi
 #### Troubleshooting your local swagger state:
 If you are having issues with your local swagger state it is recommended to run `make server_generate`, accept the prompt, and then run `make server_run` again. For more information on troubleshooting, [this](https://ustcdp3.slack.com/archives/CP6PTUPQF/p1632254277386600) explanation will be helpful.
 
-#### Defining a path for your endpoint 
+#### Defining a path for your endpoint
 For more information about URL design and structure checkout: [API Style Guide](https://transcom.github.io/mymove-docs/docs/dev/contributing/backend/API-Style-Guide)
 
 Defining your endpoint path follows this simple convention:
@@ -36,7 +40,7 @@ Defining your endpoint path follows this simple convention:
                 parameters: include parameters associated with this path
                 responses: response codes for this path, and a schema reference and the description if needed.
 
-NOTE: The description item will reference markdown files in `swagger-def/info/`. This change is further described in a recent [PR](https://github.com/transcom/mymove/pull/7435).                
+NOTE: The description item will reference markdown files in `swagger-def/info/`. This change is further described in a recent [PR](https://github.com/transcom/mymove/pull/7435).
 
 An example of the `Moves` path is as follows:
 
@@ -67,7 +71,7 @@ An example of the `Moves` path is as follows:
               $ref: 'responses/PermissionDenied.yaml'
             '500':
               $ref: '#/responses/ServerError'
-        
+
 #### Description Section and the response body
 In your endpoint description make sure that the following fields are included when necessary:
 * required - fields that are required are listed in the description section.
@@ -77,7 +81,7 @@ In your endpoint description make sure that the following fields are included wh
 * eTag - An entity tag is provided so that a browser client or a script can make conditional REST requests using optimistic concurrency control. All eTags must be marked as readOnly.
 
 An example of the ListMove description is as follows:
-        
+
           ListMove:
             description:
                 $ref: 'info/{file_name}.md'
@@ -125,11 +129,11 @@ An example of the ListMove description is as follows:
 For information on error responses, check out: [API Errors Guide](https://transcom.github.io/mymove-docs/docs/dev/contributing/backend/API-Errors#api-errors)
 
 #### Gen files:
-Once you finishing updating the yaml files with the new endpoint information make sure to run your make commands like `make swagger-generate` to autogenerate your swagger files, or simply run `make server_run`, 
+Once you finishing updating the yaml files with the new endpoint information make sure to run your make commands like `make swagger-generate` to autogenerate your swagger files, or simply run `make server_run`,
 which runs your server and other useful make commands in one go.
 
 ## Creating a Handler:
-Now you're ready to add your endpoint to the `handlers` folder. Start building out the service object before creating your handler. 
+Now you're ready to add your endpoint to the `handlers` folder. Start building out the service object before creating your handler.
 For more information about service objects and when to create one: [Service Objects](https://transcom.github.io/mymove-docs/docs/dev/contributing/backend/service-objects).
 
 An important note about service objects: The service layer is where we will store our business logic and connect to the database. Once a service object is created, it will be passed in to the handler `NewPrimeAPIHandler` function in `pkg/handlers/primeapi/api.go`,
@@ -275,3 +279,4 @@ var eventModels = map[KeyType]eventModel{
 
 
 If you'd like to learn more about event triggers, you can find more details [here](https://github.com/transcom/mymove-docs/blob/720592c63db4bffe402a801417f7c14772573c28/docs/dev/contributing/backend/How-to-Add-an-Event-Trigger.md).
+

docs/dev/versioning/How-to-deprecate-endpoints.md → docs/api/guides/how-to-deprecate-endpoints.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 5
+---
+
 # How to Deprecate an API Endpoint
 This article adheres to the principles of [API evolution](https://apisyouwonthate.com/blog/api-evolution-for-rest-http-apis), with a reduced focused on versioning. In essence, this means that we will strive to make _additive_ changes. We will introduce new functionality into the API and gradually communicate the deprecation and eventual sunsetting of the old functionality. 
 
@@ -52,4 +56,4 @@ Feel free to ping me if you have any questions. Thanks all!
 
 ## Versioning
 
-When we go live, we will have to address how we plan to _version_ our APIs, particularly for external clients. This process is still a work in progress, and [a difficult one at that](https://blog.container-solutions.com/api-versioning-what-is-it-why-so-hard). In the meantime, we will still follow the above steps for API changes that could impact our internal teams.
+When we go live, we will have to address how we plan to _version_ our APIs, particularly for external clients. This process is still a work in progress, and [a difficult one at that](https://blog.container-solutions.com/api-versioning-what-is-it-why-so-hard). In the meantime, we will still follow the above steps for API changes that could impact our internal teams.

docs/api/index.md

@@ -0,0 +1,8 @@
+---
+id: index
+sidebar_position: 1
+slug: /api
+---
+# MilMove API
+
+Here's an overview for the MilMove API.

docs/dev/testing/running-tests/Acceptance-Testing-Prime-API-Endpoints.md → docs/api/testing/acceptance-testing-prime-api-endpoints.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 1
+---
+
 # Acceptance Testing Prime API
 
 ## Current Prime API Endpoints

docs/dev/testing/running-tests/End-to-End-Testing-Playing-the-Prime.md → docs/api/testing/end-to-end-testing-playing-the-prime.md

@@ -1,6 +1,12 @@
+---
+sidebar_position: 2
+---
+
+# End to End Testing Playing the Prime
+
 This page includes instructions on how to complete basic functions as the Prime when testing the application e2e (e.g. MilMob) with other user roles (Services Counselor, TOO, TIO).
 
-### Setup
+## Setup
 
 * [Install mTLS integrations certificate](https://github.com/transcom/transcom-infrasec-com/blob/master/docs/mtls-certs.md) on your local machine
 
@@ -22,7 +28,7 @@ This page includes instructions on how to complete basic functions as the Prime
   * If you don't get a 200, check out the [Postman troubleshooting doc](https://github.com/transcom/mymove/wiki/setup-postman-to-make-mutual-tls-api-calls#troubleshooting-postman).
 
 
-### E2E Testing Sequence for 1 HHG Move
+## E2E Testing Sequence for 1 HHG Move
 
 * Customer creates move
 * Services Counselor reviews
@@ -35,7 +41,7 @@ This page includes instructions on how to complete basic functions as the Prime
 This page covers the bolded sections for Prime.
 
 
-### Prime: Part I
+## Prime: Part I
 A move must go through all previous steps before these actions can be taken, ending with TOO approval.
 
 Each request in the collection should be ran in sequence. You can edit the body as you see fit. There is code in the Tests section of some of the requests that will set variables to reuse, e.g. eTag, mtoShipmentID, etc.
@@ -68,7 +74,7 @@ Each request in the collection should be ran in sequence. You can edit the body
 
 * Wait for TOO approval
 
-### Prime: Part II
+## Prime: Part II
 Once the service items have been approved, you can create a payment request. The current setup includes two separate payment requests: One with DOSHUT service item, and one with DOFSIT service items.
 
 * Send request `createPaymentRequest1`

docs/dev/getting-started/How-to-Test-the-Prime-API.md → docs/api/testing/how-to-test-the-prime-api.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 3
+---
+
 # How to Test the Prime API
 
 > ❗ For the most up-to-date information about the Prime API, please visit https://github.com/transcom/prime_api_deliverable/wiki. The Prime API Deliverable wiki is the client-facing documentation and will be your best resource for understanding how to use this API. This article is a stub that has been kept to preserve some of the old information that might be useful for current MilMove developers.

docs/backend/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "MilMove Backend",
+  "position": 1
+}

docs/backend/guides/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Guides",
+  "position": 3,
+  "collapsed": true
+}

docs/dev/contributing/backend/access-global-variables.md → docs/backend/guides/access-global-variables.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 9
+---
+
 # How to Access a Global Application Variable
 
 ## Overview