|
3 | 3 | page_title: "readme_api_specification Resource - readme"
|
4 | 4 | subcategory: ""
|
5 | 5 | 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. |
8 | 9 | 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). |
10 | 13 | 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. |
15 | 20 | ---
|
16 | 21 |
|
17 | 22 | # readme_api_specification (Resource)
|
18 | 23 |
|
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. |
22 | 27 |
|
23 | 28 | ## 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). |
26 | 32 |
|
27 | 33 | ## 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. |
28 | 36 |
|
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. |
32 | 40 |
|
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. |
36 | 42 |
|
37 | 43 | ## Example Usage
|
38 | 44 |
|
@@ -83,25 +89,23 @@ resource "readme_doc" "example" {
|
83 | 89 |
|
84 | 90 | ### Required
|
85 | 91 |
|
86 |
| -- `definition` (String) The raw API specification definition JSON. |
| 92 | +- `definition` (String) Raw API specification definition in JSON format. |
87 | 93 |
|
88 | 94 | ### Optional
|
89 | 95 |
|
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). |
94 | 98 |
|
95 | 99 | ### Read-Only
|
96 | 100 |
|
97 | 101 | - `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. |
105 | 109 |
|
106 | 110 | <a id="nestedatt--category"></a>
|
107 | 111 | ### Nested Schema for `category`
|
|
0 commit comments