chore: add links between AEPs (#327)

* chore: add links between AEPs

* fix: add missing link

Author: ndrpnt

aep/general/0001/aep.md.j2

@@ -33,7 +33,7 @@ Companies **may** adopt the AEP system in one of two ways:
 Companies with an already-established corpus of services are unlikely to have
 exactly followed the guidance at [aep.dev][]. Forking the system is valuable
 because the guidance becomes comparable. Forks **must** retain the same
-numbering system (AEP-2) to provide that comparability.
+numbering system [AEP-2][aep-2] to provide that comparability.
 
 ### Technical leadership
 
@@ -219,3 +219,4 @@ approved, will replace the old one. The old one then enters "Replaced" state,
 and will link to the new, current AEP.
 
 [aep.dev]: https://aep.dev/
+[aep-2]: ./0002.md

aep/general/0127/aep.md.j2

@@ -121,6 +121,7 @@ rpc CreateBook(CreateBookRequest) returns (Book) {
 
 <!-- prettier-ignore-start -->
 [json encoding]: https://developers.google.com/protocol-buffers/docs/proto3#json
+[resources]: ./0121.md
 [rpc]: https://en.wikipedia.org/wiki/Remote_procedure_call
 [google.api.http]: https://buf.build/googleapis/googleapis/docs/main:google.api#google.api.Http
 <!-- prettier-ignore-end -->

aep/general/0131/aep.md.j2

@@ -4,9 +4,9 @@ In REST APIs, it is customary to make a `GET` request to a resource's URI (for
 example, `/v1/publishers/{publisher_id}/books/{book_id}`) in order to retrieve
 that resource.
 
-Resource-oriented design (AEP-121) honors this pattern through the `Get`
-method. These RPCs accept the URI representing that resource and return the
-resource.
+Resource-oriented design [AEP-121][aep-121] honors this pattern through the
+`Get` method. These RPCs accept the URI representing that resource and return
+the resource.
 
 ## Guidance
 
@@ -142,3 +142,5 @@ exist, the service **must** reply with an HTTP 404 error.
 {% sample '../example.oas.yaml', '$.paths./publishers/{publisher_id}/books/{book_id}.get' %}
 
 {% endtabs %}
+
+[aep-121]: ./0121.md

aep/general/0132/aep.md.j2

@@ -4,9 +4,9 @@ In REST APIs, it is customary to make a `GET` request to a resource
 collection's URI (for example, `/publishers/{publisher_id}/books`) in order to
 retrieve a list of the resources within that collection.
 
-Resource-oriented design (AEP-121) honors this pattern through the `List`
-method. These RPCs accept a parent collection (if one exists), and return a
-list of responses matching that input.
+Resource-oriented design [AEP-121][aep-121] honors this pattern through the
+`List` method. These RPCs accept a parent collection (if one exists), and
+return a list of responses matching that input.
 
 ## Guidance
 
@@ -221,5 +221,6 @@ soft-deleted resources to be included.
 [reading across collections]: ./0159
 [soft-delete]: ./0164
 [resource type]: ./0123
+[aep-121]: ./0121
 [aep-203]: ./0203
 <!-- prettier-ignore-end -->

aep/general/0133/aep.md.j2

@@ -4,10 +4,10 @@ In REST APIs, it is customary to make a `POST` request to a collection's URI
 (for example, `/v1/publishers/{publisher_id}/books`) in order to create a new
 resource within that collection.
 
-Resource-oriented design (AEP-121) honors this pattern through the `Create`
-method. These RPCs accept the parent collection if one exists, and the resource
-to create (and potentially some other parameters), and return the created
-resource.
+Resource-oriented design [AEP-121][aep-121] honors this pattern through the
+`Create` method. These RPCs accept the parent collection if one exists, and the
+resource to create (and potentially some other parameters), and return the
+created resource.
 
 ## Guidance
 

aep/general/0134/aep.md.j2

@@ -4,9 +4,9 @@ In REST APIs, it is customary to make a `PATCH` or `PUT` request to a
 resource's URI (for example, `/v1/publishers/{publisher_id}/books/{book_id}`)
 in order to update that resource.
 
-Resource-oriented design (AEP-121) honors this pattern through the `Update`
-method (which mirrors the REST `PATCH` behavior). These methods accept the URI
-representing that resource and return the resource.
+Resource-oriented design [AEP-121][aep-121] honors this pattern through the
+`Update` method (which mirrors the REST `PATCH` behavior). These methods accept
+the URI representing that resource and return the resource.
 
 Also see the [apply](/apply) method, with guidance on how to implement `PUT`
 requests.

aep/general/0136/aep.md.j2

@@ -1,8 +1,8 @@
 # Custom methods
 
-Resource oriented design (AEP-121) uses custom methods to provide a means to
-express actions that are difficult to model using only the standard methods.
-Custom methods are important because they provide a means for an API's
+Resource oriented design [AEP-121][aep-121] uses custom methods to provide a
+means to express actions that are difficult to model using only the standard
+methods. Custom methods are important because they provide a means for an API's
 vocabulary to adhere to user intent.
 
 ## Guidance
@@ -131,6 +131,7 @@ around state management to determine when the custom method should be invoked.
 AEP's supported declarative clients cannot support custom methods.
 
 <!-- prettier-ignore-start -->
+[aep-121]: ./0121.md
 [rfc 5789]: https://datatracker.ietf.org/doc/html/rfc5789
 [rfc 7231 section 4.2.1]: https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.1
 [rfc 7231 section 4.3]: https://datatracker.ietf.org/doc/html/rfc7231#section-4.3

aep/general/0164/aep.md.j2

@@ -17,7 +17,7 @@ updated resource instead of `204 No Content`.
 
 Resources that support soft delete **should** have an `expire_time` field as
 described in AEP-148. Additionally, resources **should** include a `DELETED`
-state value if the resource includes a `state` field (AEP-216).
+state value if the resource includes a `state` field [AEP-216][aep-216].
 
 ### Undelete
 
@@ -64,28 +64,28 @@ A resource that supports soft delete **should** provide an `Undelete` method:
 
 Some resources take longer to undelete a resource than is reasonable for a
 regular API request. In this situation, the API **should** follow the
-long-running request pattern (AEP-151).
+long-running request pattern [AEP-151][aep-151].
 
 ### List and Get
 
-Soft-deleted resources **should not** be returned in `List` (AEP-132) responses
-by default (unless `bool show_deleted` is true).
+Soft-deleted resources **should not** be returned in `List` [AEP-132][aep-132]
+responses by default (unless `bool show_deleted` is true).
 
-A `Get` (AEP-131) request for a soft deleted resource **should** error with
-`410 Gone` unless `bool show_deleted` is true, in which case soft-deleted
+A `Get` [AEP-131][aep-131] request for a soft deleted resource **should** error
+with `410 Gone` unless `bool show_deleted` is true, in which case soft-deleted
 resources **must** return the resource.
 
 Services that soft delete resources **may** choose a reasonable strategy for
 purging those resources, including automatic purging after a reasonable time
-(such as 30 days), allowing users to set an expiry time (AEP-214), or retaining
-the resources indefinitely. Regardless of what strategy is selected, the
-service **should** document when soft deleted resources will be completely
+(such as 30 days), allowing users to set an expiry time [AEP-214][aep-214], or
+retaining the resources indefinitely. Regardless of what strategy is selected,
+the service **should** document when soft deleted resources will be completely
 removed.
 
 ### Declarative-friendly resources
 
-A resource that is declarative-friendly (AEP-128) **should** support soft
-delete and undelete.
+A resource that is declarative-friendly [AEP-128][aep-128] **should** support
+soft delete and undelete.
 
 **Important:** There is an ambiguity in declarative tooling between "create"
 and "undelete". When given an alias which was previously deleted and a
@@ -100,8 +100,8 @@ Declarative-friendly resources **must** use long-running operations for both
 soft delete and undelete. The service **may** return an LRO that is already set
 to done if the request is effectively immediate.
 
-Declarative-friendly resources **must** include `validate_only` (AEP-163) and
-`etag` (AEP-154) in their `Undelete` methods.
+Declarative-friendly resources **must** include `validate_only`
+[AEP-163][aep-163] and `etag` [AEP-154][aep-154] in their `Undelete` methods.
 
 ### Errors
 
@@ -123,9 +123,17 @@ resource is not deleted, the service **must** error with `409 Conflict`.
 
 ## Further reading
 
-- For the `Delete` standard method, see AEP-135.
-- For long-running operations, see AEP-151.
-- For resource freshness validation (`etag`), see AEP-154.
-- For change validation (`validate_only`), see AEP-163.
+- For the `Delete` standard method, see [AEP-135][aep-135].
+- For long-running operations, see [AEP-151][aep-151].
+- For resource freshness validation (`etag`), see [AEP-154][aep-154].
+- For change validation (`validate_only`), see [AEP-163][aep-163].
 
 [aep-4]: ./0004.md
+[aep-128]: ./0128.md
+[aep-131]: ./0131.md
+[aep-135]: ./0135.md
+[aep-151]: ./0151.md
+[aep-154]: ./0154.md
+[aep-163]: ./0163.md
+[aep-214]: ./0214.md
+[aep-216]: ./0216.md

aep/general/0193/aep.md.j2

@@ -148,13 +148,14 @@ does not exist, the service **must** error with `NOT_FOUND` (HTTP 404).
 ## Further reading
 
 - [RFC 9457 Problem Details for HTTP APIs][RFC 9457]
-- For which error codes to retry, see [AEP-194](https://aep.dev/194).
+- For which error codes to retry, see [AEP-194][aep-194].
 
 ## Changelog
 
 - **2024-03-21**: Adopt from https://google.aip.dev/193
 
 <!-- prettier-ignore-start -->
+[aep-194]: ./194.md
 [RFC 9457]: https://datatracker.ietf.org/doc/html/rfc9457
 [grpc status code documentation]: https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
 [Code]: https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto