Chore/api reference scripts delete#444
Conversation
| Updates properties (`name`, `description`, and `script`) of an invokable script. | ||
| Updates an invokable script. | ||
|
|
||
| Use this endpoint to update the properties (`description`, and `script`) |
There was a problem hiding this comment.
| Use this endpoint to update the properties (`description`, and `script`) | |
| Use this endpoint to modify values for script properties (`description` and `script`). |
| Updates an invokable script. | ||
|
|
||
| Use this endpoint to update the properties (`description`, and `script`) | ||
| of an invokable script. |
There was a problem hiding this comment.
| of an invokable script. |
|
|
||
| #### Limitations | ||
|
|
||
| - Sending an empty request body returns an HTTP `200` status code. |
There was a problem hiding this comment.
| - Sending an empty request body returns an HTTP `200` status code. | |
| - If you send an empty request body, InfluxDB responds with an HTTP `200` status code. |
| examples: | ||
| notFound: | ||
| summary: | | ||
| The requested script was not found. |
There was a problem hiding this comment.
| The requested script was not found. | |
| The requested script wasn't found. |
|
|
||
| #### Limitations | ||
|
|
||
| - Only one script can be deleted per request. |
There was a problem hiding this comment.
| - Only one script can be deleted per request. | |
| - You can delete only one script per request. |
| #### Limitations | ||
|
|
||
| - Only one script can be deleted per request. | ||
| - `scriptIDs` that do not exist return an HTTP `204` status code. |
There was a problem hiding this comment.
| - `scriptIDs` that do not exist return an HTTP `204` status code. | |
| - If the script ID you provide doesn't exist for the organization, InfluxDB responds with an HTTP `204` status code. |
| Script ID. | ||
| Only returns the script with this ID. |
There was a problem hiding this comment.
| Script ID. | |
| Only returns the script with this ID. | |
| The ID of the script to retrieve. |
I suppose we could apply that same pattern (like you did here) to all the GET ...${ID} operations. Makes things easier for us and is more descriptive.
I've following Square's convention with "The ID of the...".
What do you think? We should still lead with the article, though: "The script ID."
There was a problem hiding this comment.
I think i like how square is wording it. "The ID of the..." sounds good to me
| #### Limitations | ||
|
|
||
| - You can delete only one script per request. | ||
| - If the script ID you provide doesnt exist for the organization, InfluxDB |
There was a problem hiding this comment.
| - If the script ID you provide doesnt exist for the organization, InfluxDB | |
| - If the script ID you provide doesn't exist for the organization, InfluxDB |
| required: true | ||
| description: The ID of the script to delete. | ||
| description: | | ||
| Script ID. |
There was a problem hiding this comment.
| Script ID. | |
| The script ID. |
| Updates properties (`name`, `description`, and `script`) of an invokable script. | ||
| Updates an invokable script. | ||
|
|
||
| Use this endpoint to modify values for script properties (`description`, and `script`). |
There was a problem hiding this comment.
| Use this endpoint to modify values for script properties (`description`, and `script`). | |
| Use this endpoint to modify values for script properties (`description` and `script`). |
|
|
||
| #### Limitations | ||
|
|
||
| - If you send an empty request body, InfluxDB responds with an HTTP `200` |
There was a problem hiding this comment.
Does this store an empty script?
There was a problem hiding this comment.
It does not store an empty script. i'll add an additional statement saying that it does not store an empty script / does not update the script
| #### Limitations | ||
|
|
||
| - You can delete only one script per request. | ||
| - If the script ID you provide doesn't exist for the organization, InfluxDB |
| description: The requested script object. | ||
| description: | | ||
| Success. | ||
| The response body contains the script object. |
There was a problem hiding this comment.
| The response body contains the script object. | |
| The response body contains the script detail. |
|
|
||
| #### Limitations | ||
|
|
||
| - If you send an empty request body, the script will neither update nor |
There was a problem hiding this comment.
It doesn't create a script object with an empty script?
| requestBody: | ||
| description: Script update to apply | ||
| description: | | ||
| An object that contains the updated script properties to apply. |
There was a problem hiding this comment.
My preference is to avoid mentioning "object" given that it's content-type (JSON) specific... even though it's the only content-type. I'm sure I break this rule occasionally.
There was a problem hiding this comment.
e.g. See how https://developers.google.com/youtube/v3/docs/playlistItems/insert?hl=en_US and https://developer.squareup.com/reference/square/payments-api/create-payment both avoid using content-type specific language. YouTube uses more HTTP/REST-ish descriptions like `resource' with a link to the schema entity. Square doesn't usually describe the payload as a thing, just the "Payment" and the fields.
There was a problem hiding this comment.
I think what you did is more practical, but maybe we could show it with an example instead of describe it.
| required: true | ||
| description: The script ID. | ||
| description: | | ||
| Script ID. |
There was a problem hiding this comment.
| Script ID. |
| source: | | ||
| curl -X 'PATCH' \ | ||
| "https://cloud2.influxdata.com/api/v2/scripts/SCRIPT_ID" \ | ||
| --header "Authorization: Token INFLUX_TOKEN" \ |
There was a problem hiding this comment.
| --header "Authorization: Token INFLUX_TOKEN" \ | |
| --header "Authorization: Token INFLUX_API_TOKEN" \ |
| --header "Accept: application/json" | ||
| --header "Content-Type: application/json" | ||
| --data '{ | ||
| "description": "get last point from new bucket", |
There was a problem hiding this comment.
| "description": "get last point from new bucket", | |
| "description": "Get the last point from the bucket", |
| Use this endpoint to update the properties (`name`, `description`, and `script`) of an invokable script. | ||
| Use this endpoint to modify values for script properties (`description` and `script`). | ||
|
|
||
| To update a script, pass an object that contains the updated key-value pairs. |
There was a problem hiding this comment.
Let's use the requestBody description for this and not duplicate.
| To update a script, pass an object that contains the updated key-value pairs. |
| requestBody: | ||
| description: The script update to apply. | ||
| description: | | ||
| An object that contains the updated script properties to apply. |
There was a problem hiding this comment.
| An object that contains the updated script properties to apply. | |
| In the request body, provide the script properties to update. |
This is my new pattern. Eventually, I plan to append an statement (with redoc-cli) that introduces the properties that can be set, like in YouTube docs--"You can set the following properties for this resource:"
* 'master' of github.com:influxdata/openapi: chore: use /latest alias for OSS URL substitutions. (#603) fix(bucket schemas): `requestBody` for `createMeasurementSchema` and `updateMeasurementSchema` should be required (#607) fix(tasks): `orgID` should not be required for GetTasks (#606) chore(aim): Add Operator Entitlements Endpoints (#595) chore(aim): Add 403 to Org Creation Endpoints (#597) chore(invocable-scripts): add /api/v2/scripts/SCRIPT_ID/params (#593) Chore/api reference scripts delete (#444)
Delete script
Get script
Patch script