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

Update cat API docs with guidance on intended use cases #51772

Closed
cjcenizal opened this issue Jan 31, 2020 · 4 comments · Fixed by #52727
Closed

Update cat API docs with guidance on intended use cases #51772

cjcenizal opened this issue Jan 31, 2020 · 4 comments · Fixed by #52727
Assignees
Labels
:Data Management/CAT APIs Text APIs behind /_cat >docs General docs changes

Comments

@cjcenizal
Copy link
Contributor

cjcenizal commented Jan 31, 2020

Per conversation with @jaymode, the cat API is intended for consumption via Console and the command line. It's not intended for consumers who are writing application code.

Kibana consumes the cat API at numerous points (example: elastic/kibana#56532). To help Kibana engineers (and other application developers) migrate away from cat and avoid consuming it in the future, I think we should update the docs with a clear explanation of the purpose behind the cat API, including details on why it's problematic to consume it in application code, and advise application developers to use the other APIs.

@jaymode jaymode added :Data Management/CAT APIs Text APIs behind /_cat >docs General docs changes labels Jan 31, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features (:Core/Features/CAT APIs)

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-docs (>docs)

@jaymode
Copy link
Member

jaymode commented Jan 31, 2020

including details on why it's problematic to consume it in application code

The Elasticsearch team discussed this a few months back during a discussion regarding system indices. Ideally by keeping the system and hidden indices out of the cat APIs, we can keep the APIs simpler. Additionally, we would like some additional freedom in the cat API output such that we could add a new column (may be in the middle of existing columns), which may more easily be handled by the human eye than an application (depending on how its parsing is implemented). If we have applications depending on the cat API and we don't expect them to be depending on the cat API, a change we make could break the application which is something we would like to avoid.

@jasontedor may have other points and be able to articulate the reasoning better than I can.

@jasontedor
Copy link
Member

I think our [docs] allude to the reason that @jaymode expands on well:

JSON is great…​ for computers. Even if it’s pretty-printed, trying to find relationships in the data is tedious. Human eyes, especially when looking at a terminal, need compact and aligned text. The cat API aims to meet this need.

The cat API is meant for human consumption, and interaction with via command-line tools. It is not meant for consumption in applications, it's not designed/developed for that, and we don't intend for it to be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/CAT APIs Text APIs behind /_cat >docs General docs changes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants