Human flag to be moved under always accepted query_string params #22562
Conversation
There are some parameters that are accepted by each and every api we expose. Those (pretty, source, error_trace and filter_path) are not explicitly listed in the spec of every api, rather whitelisted in clients test runners so that they are always accepted. The `human` flag has been treated up until now as a parameter that's accepted by only some stats and info api, but that doesn't reflect reality as es core treats it exactly like `pretty` (relevant especially now that we validate params and throw exception when we find one that is not supported). Furthermore, the human flag has effect on every api that outputs a date, time, percentage or byte size field. For instance the tasks api outputs a date field although they don't have the human flag explicitly listed in their spec. There are other similar cases. This commit removes the human flag from the rest spec and makes it an always accepted query_string param.
javanna
added
:Core/Infra/REST API
|
@elastic/es-clients are we all good with this change? |
nik9000
left a comment
nik9000
left a comment
There was a problem hiding this comment.
Makes sense to me though this should probably wait on es-clients so it doesn't break them.
|
agreed, everybody has to upgrade their list of always accepted query_string params. When everyone has done that, we can safely push I think. |
|
++ on my end |
|
++ good on our end as well. We'll need to make a minor adjustment in the .NET client, but it won't break us. Related, it's probably a good idea to include these global params somewhere in the spec. I opened #11638 a while back, perhaps now is a good time to revisit it. |
|
I already include the
I think in the past we have agreed that core can (and sometimes must) move faster, so breaking the integrations is not a problem per se. We have only asked for a notification (like this one), so we know what's gonna happen. |
+1 Go for it |
) There are some parameters that are accepted by each and every api we expose. Those (pretty, source, error_trace and filter_path) are not explicitly listed in the spec of every api, rather whitelisted in clients test runners so that they are always accepted. The `human` flag has been treated up until now as a parameter that's accepted by only some stats and info api, but that doesn't reflect reality as es core treats it exactly like `pretty` (relevant especially now that we validate params and throw exception when we find one that is not supported). Furthermore, the human flag has effect on every api that outputs a date, time, percentage or byte size field. For instance the tasks api outputs a date field although they don't have the human flag explicitly listed in their spec. There are other similar cases. This commit removes the human flag from the rest spec and makes it an always accepted query_string param.
6 participants
There are some parameters that are accepted by each and every api we expose. Those (pretty, source, error_trace and filter_path) are not explicitly listed in the spec of every api, rather whitelisted in clients test runners so that they are always accepted. The
humanflag has been treated up until now as a parameter that's accepted by only some stats and info api, but that doesn't reflect reality as es core treats it exactly likepretty(relevant especially now that we validate params and throw exception when we find one that is not supported). Furthermore, the human flag has effect on every api that outputs a date, time, percentage or byte size field. For instance the tasks api outputs a date field although they don't have the human flag explicitly listed in their spec. There are other similar cases. This commit removes the human flag from the rest spec and makes it an always accepted query_string param.