Skip to content

Commit ba91ac0

Browse files
committed
Refactor API specification resource for clarity and consistency
- Consolidated the long API specification description into a global constant for improved readability. - Renamed `apiSpecificationResource` to `apiSpecResource` and updated related structs and methods for consistency. - Replaced `jsonMatch` function with a more robust implementation. - Improved error handling and logging across the resource methods. - Added `TestJsonMatch` unit tests to validate the JSON comparison logic. - General cleanup and code structure improvements for maintainability.
1 parent 9d5ab9f commit ba91ac0

File tree

3 files changed

+402
-284
lines changed

3 files changed

+402
-284
lines changed

docs/resources/api_specification.md

Lines changed: 34 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -3,36 +3,42 @@
33
page_title: "readme_api_specification Resource - readme"
44
subcategory: ""
55
description: |-
6-
Manages an API specification on ReadMe.com
7-
The provider creates and updates API specifications by first uploading the definition to the API registry and then creating or updating the API specification using the UUID returned from the API registry. This is necessary for associating an API specification with its definition. Ensuring the definition is created in the API registry is necessary for retrieving the remote definition. This behavior is undocumented in the ReadMe API documentation but works the same way the official ReadMe rdme CLI tool works.
6+
Manages API specifications on ReadMe.com by uploading the definition to the API registry and associating it with the
7+
specification using the returned UUID. This association is necessary for managing the API specification and its
8+
definition. The behavior is similar to the official rdme CLI but is undocumented in the ReadMe API.
89
External Changes
9-
External changes made to an API specification managed by Terraform will not be detected due to the way the API registry works. When a specification definition is updated, the registry UUID changes and is only available from the response when the definition is published to the registry. When Terraform runs after an external update, there's no way of programatically retrieving the current state without the current UUID. Forcing a Terraform update (e.g. tainting or a manual change) will get things synchronized again.
10+
External changes to API specifications managed by Terraform are not automatically detected. The UUID changes when a
11+
definition is updated, and the new UUID is only available when published to the registry. To synchronize, force an
12+
update via Terraform (e.g., taint or manual change).
1013
Importing Existing Specifications
11-
Importing API specifications is limited due to the behavior of the API registry and associating a specification with its definition. When importing, Terraform will replace the remote definition on its next run, regardless if it differs from the local definition. This will associate a registry UUID with the specification.
12-
Managing API Specification Docs
13-
API Specifications created in ReadMe can have a documentation page associated with them. This is automatically created by ReadMe when a specification is created. The documentation page is not implicitly managed by Terraform. To manage the documentation page, use the readme_doc resource with the use_slug attribute set to the API specification tag slug.
14-
See https://docs.readme.com/main/reference/uploadapispecification for more information about this API endpoint.
14+
Importing is limited due to how the API registry associates specifications with definitions. Terraform will overwrite
15+
the remote definition on the next run, replacing the UUID.
16+
Managing Documentation
17+
API specifications on ReadMe automatically create a documentation page, but it isn't managed by Terraform. Use the
18+
readme_doc resource with use_slug to manage the documentation page.
19+
See the ReadMe API documentation at https://docs.readme.com/main/reference/uploadapispecification for more information.
1520
---
1621

1722
# readme_api_specification (Resource)
1823

19-
Manages an API specification on ReadMe.com
20-
21-
The provider creates and updates API specifications by first uploading the definition to the API registry and then creating or updating the API specification using the UUID returned from the API registry. This is necessary for associating an API specification with its definition. Ensuring the definition is created in the API registry is necessary for retrieving the remote definition. This behavior is undocumented in the ReadMe API documentation but works the same way the official ReadMe `rdme` CLI tool works.
24+
Manages API specifications on ReadMe.com by uploading the definition to the API registry and associating it with the
25+
specification using the returned UUID. This association is necessary for managing the API specification and its
26+
definition. The behavior is similar to the official rdme CLI but is undocumented in the ReadMe API.
2227

2328
## External Changes
24-
25-
External changes made to an API specification managed by Terraform will not be detected due to the way the API registry works. When a specification definition is updated, the registry UUID changes and is only available from the response when the definition is published to the registry. When Terraform runs after an external update, there's no way of programatically retrieving the current state without the current UUID. Forcing a Terraform update (e.g. tainting or a manual change) will get things synchronized again.
29+
External changes to API specifications managed by Terraform are not automatically detected. The UUID changes when a
30+
definition is updated, and the new UUID is only available when published to the registry. To synchronize, force an
31+
update via Terraform (e.g., taint or manual change).
2632

2733
## Importing Existing Specifications
34+
Importing is limited due to how the API registry associates specifications with definitions. Terraform will overwrite
35+
the remote definition on the next run, replacing the UUID.
2836

29-
Importing API specifications is limited due to the behavior of the API registry and associating a specification with its definition. When importing, Terraform will replace the remote definition on its next run, regardless if it differs from the local definition. This will associate a registry UUID with the specification.
30-
31-
## Managing API Specification Docs
37+
## Managing Documentation
38+
API specifications on ReadMe automatically create a documentation page, but it isn't managed by Terraform. Use the
39+
readme_doc resource with use_slug to manage the documentation page.
3240

33-
API Specifications created in ReadMe can have a documentation page associated with them. This is automatically created by ReadMe when a specification is created. The documentation page is not implicitly managed by Terraform. To manage the documentation page, use the `readme_doc` resource with the `use_slug` attribute set to the API specification tag slug.
34-
35-
See <https://docs.readme.com/main/reference/uploadapispecification> for more information about this API endpoint.
41+
See the ReadMe API documentation at https://docs.readme.com/main/reference/uploadapispecification for more information.
3642

3743
## Example Usage
3844

@@ -83,25 +89,23 @@ resource "readme_doc" "example" {
8389

8490
### Required
8591

86-
- `definition` (String) The raw API specification definition JSON.
92+
- `definition` (String) Raw API specification definition in JSON format.
8793

8894
### Optional
8995

90-
- `delete_category` (Boolean) Delete the category associated with the API specification when the resource is deleted.
91-
- `semver` (String) The semver(-ish) of the API specification. This value may also be set in the definition JSON `info:version` key, but will be ignored if this attribute is set. Changing the version of a created resource will replace the API specification. Use unique resources to use the same specification across multiple versions.
92-
93-
Learn more about document versioning at <https://docs.readme.com/main/docs/versions>.
96+
- `delete_category` (Boolean) Delete the associated category when the resource is deleted.
97+
- `semver` (String) Semver (or similar) for the API specification. This value can be set in the `info:version` key of the definition JSON, but this parameter takes precedence. Changing the version will replace the API specification. Use unique resources for multiple versions. Learn more about document versioning [here](https://docs.readme.com/main/docs/versions).
9498

9599
### Read-Only
96100

97101
- `category` (Object) Category metadata for the API specification. (see [below for nested schema](#nestedatt--category))
98-
- `id` (String) The unique identifier of the API specification.
99-
- `last_synced` (String) Timestamp of last synchronization.
100-
- `source` (String) The creation source of the API specification.
101-
- `title` (String) The title of the API specification derived from the specification JSON.
102-
- `type` (String) The type of the API specification.
103-
- `uuid` (String) The API registry UUID associated with the specification.
104-
- `version` (String) The version ID the API specification is associated with.
102+
- `id` (String) Unique identifier of the API specification.
103+
- `last_synced` (String) Timestamp of the last synchronization.
104+
- `source` (String) Creation source of the API specification.
105+
- `title` (String) Title derived from the specification JSON.
106+
- `type` (String) Type of the API specification.
107+
- `uuid` (String) UUID of the API registry associated with this specification.
108+
- `version` (String) Version ID associated with the API specification.
105109

106110
<a id="nestedatt--category"></a>
107111
### Nested Schema for `category`

0 commit comments

Comments
 (0)