-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DOCS] Add info about GET/POST to the API conventions. #74529
Conversation
@elasticmachine retest this please |
@elasticmachine retest this please |
Pinging @elastic/es-core-infra (Team:Core/Infra) |
Pinging @elastic/es-docs (Team:Docs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I left some minor feedback but nothing blocking. Thanks!
A number of {es} GET APIs--most notably the search API--support passing parameters | ||
in the body of the request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be simpler to just say support a request body.
As written, users could interpret this to mean I can pass any query parameters in the request body, which isn't usually true.
While the GET action makes sense in the context of retrieving information, | ||
GET requests with a body are not supported by all HTTP libraries. | ||
(RFC 7231 doesn't define how GET requests with a body should be handled, | ||
so they are not allowed by all HTTP servers.) | ||
|
||
* <<multi-index>> | ||
* <<date-math-index-names>> | ||
* <<cron-expressions>> | ||
* <<common-options>> | ||
* <<url-access-control>> | ||
Because GET requests with bodies are not universally supported, | ||
all {es} GET APIs that require a body can also be submitted as POST requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd combine these paragraphs and remove the parenthetical. Something like:
Because not all HTTP servers allow GET requests with a body, these APIs also
support the POST method.
[discrete] | ||
[[api-conventions-parameters]] | ||
=== Parameters | ||
|
||
Rest parameters (when using HTTP, map to HTTP URL parameters) follow the | ||
convention of using underscore casing. | ||
|
||
[discrete] | ||
=== Boolean Values | ||
|
||
All REST API parameters (both request parameters and JSON body) support | ||
providing boolean "false" as the value `false` and boolean "true" as the | ||
value `true`. All other values will raise an error. | ||
|
||
[discrete] | ||
==== Number Values | ||
|
||
All REST APIs support providing numbered parameters as `string` on top | ||
of supporting the native JSON number types. | ||
|
||
[discrete] | ||
[[time-units]] | ||
=== Time units | ||
|
||
Whenever durations need to be specified, e.g. for a `timeout` parameter, the duration must specify | ||
the unit, like `2d` for 2 days. The supported units are: | ||
|
||
[horizontal] | ||
`d`:: Days | ||
`h`:: Hours | ||
`m`:: Minutes | ||
`s`:: Seconds | ||
`ms`:: Milliseconds | ||
`micros`:: Microseconds | ||
`nanos`:: Nanoseconds | ||
|
||
[[byte-units]] | ||
[discrete] | ||
=== Byte size units | ||
|
||
Whenever the byte size of data needs to be specified, e.g. when setting a buffer size | ||
parameter, the value must specify the unit, like `10kb` for 10 kilobytes. Note that | ||
these units use powers of 1024, so `1kb` means 1024 bytes. The supported units are: | ||
|
||
[horizontal] | ||
`b`:: Bytes | ||
`kb`:: Kilobytes | ||
`mb`:: Megabytes | ||
`gb`:: Gigabytes | ||
`tb`:: Terabytes | ||
`pb`:: Petabytes | ||
|
||
[[size-units]] | ||
[discrete] | ||
=== Unit-less quantities | ||
|
||
Unit-less quantities means that they don't have a "unit" like "bytes" or "Hertz" or "meter" or "long tonne". | ||
|
||
If one of these quantities is large we'll print it out like 10m for 10,000,000 or 7k for 7,000. We'll still print 87 | ||
when we mean 87 though. These are the supported multipliers: | ||
|
||
[horizontal] | ||
`k`:: Kilo | ||
`m`:: Mega | ||
`g`:: Giga | ||
`t`:: Tera | ||
`p`:: Peta | ||
|
||
[[distance-units]] | ||
[discrete] | ||
=== Distance Units | ||
|
||
Wherever distances need to be specified, such as the `distance` parameter in | ||
the <<query-dsl-geo-distance-query>>), the default unit is meters if none is specified. | ||
Distances can be specified in other units, such as `"1km"` or | ||
`"2mi"` (2 miles). | ||
|
||
The full list of units is listed below: | ||
|
||
[horizontal] | ||
Mile:: `mi` or `miles` | ||
Yard:: `yd` or `yards` | ||
Feet:: `ft` or `feet` | ||
Inch:: `in` or `inch` | ||
Kilometer:: `km` or `kilometers` | ||
Meter:: `m` or `meters` | ||
Centimeter:: `cm` or `centimeters` | ||
Millimeter:: `mm` or `millimeters` | ||
Nautical mile:: `NM`, `nmi`, or `nauticalmiles` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd consider moving these sections to the conventions page as they're not really about options/parameters.
[discrete] | ||
=== Request body in query string | ||
|
||
For libraries that don't accept a request body for non-POST requests, | ||
you can pass the request body as the `source` query string parameter | ||
instead. When using this method, the `source_content_type` parameter | ||
should also be passed with a media type value that indicates the format | ||
of the source, such as `application/json`. | ||
|
||
[discrete] | ||
=== Content-type requirements | ||
|
||
The type of the content sent in a request body must be specified using | ||
the `Content-Type` header. The value of this header must map to one of | ||
the supported formats that the API supports. Most APIs support JSON, | ||
YAML, CBOR, and SMILE. The bulk and multi-search APIs support NDJSON, | ||
JSON, and SMILE; other types will result in an error response. | ||
|
||
When using the `source` query string parameter, the content type must be | ||
specified using the `source_content_type` query string parameter. | ||
|
||
{es} only supports UTF-8-encoded JSON. {es} ignores any other encoding headings | ||
sent with a request. Responses are also UTF-8 encoded. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move these sections to the conventions page.
Thanks for the review! I streamlined things a bit more, moved the rest of the conventions to the conventions, and organized them in more logical groupings. |
@elasticmachine retest this please |
@elasticmachine retest this please |
@elasticmachine retest this please |
Note that Elasticsearch GET APIs that support a request body can also be submitted as POST requests.