Skip to content
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

Merged
merged 4 commits into from
Jun 30, 2021

Conversation

debadair
Copy link
Contributor

Note that Elasticsearch GET APIs that support a request body can also be submitted as POST requests.

@debadair
Copy link
Contributor Author

@elasticmachine retest this please

@debadair
Copy link
Contributor Author

@elasticmachine retest this please

@debadair debadair requested review from gwbrown and jrodewig June 28, 2021 20:49
@debadair debadair added :Core/Infra/REST API REST infrastructure and utilities >docs General docs changes v7.14.0 v8.0.0 v7.13.3 labels Jun 28, 2021
@debadair debadair marked this pull request as ready for review June 28, 2021 20:51
@elasticmachine elasticmachine added Team:Core/Infra Meta label for core/infra team Team:Docs Meta label for docs team labels Jun 28, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-docs (Team:Docs)

Copy link
Contributor

@jrodewig jrodewig left a 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!

Comment on lines 11 to 12
A number of {es} GET APIs--most notably the search API--support passing parameters
in the body of the request.
Copy link
Contributor

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.

Comment on lines 13 to 19
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.
Copy link
Contributor

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.

Comment on lines 299 to 387
[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`
Copy link
Contributor

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.

Comment on lines 498 to 520
[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.
Copy link
Contributor

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.

@debadair
Copy link
Contributor Author

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.

@debadair
Copy link
Contributor Author

@elasticmachine retest this please

@debadair
Copy link
Contributor Author

@elasticmachine retest this please

2 similar comments
@debadair
Copy link
Contributor Author

@elasticmachine retest this please

@debadair
Copy link
Contributor Author

@elasticmachine retest this please

@debadair
Copy link
Contributor Author

@elasticmachine retest this please

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/REST API REST infrastructure and utilities >docs General docs changes Team:Core/Infra Meta label for core/infra team Team:Docs Meta label for docs team v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants