Java high-level REST client completeness #27205
Comments
|
I updated the description of the issue by assigning each API a rank from 1 to 3 based on how difficult it should be to add support for it to the high-level REST client. Criterias were mainly how big the request is to serialize and how big the response is to parse back. |
|
thanks @javanna - I've separated the APIs into "important" and "optional" lists, where optional APIs are ones that will seldom be used from applications other than monitoring applications or tests. If anybody disagrees with my selection, feel free to mention which APIs should be marked as important. |
|
Not using the high-level REST client yet, but I would really have expected that multi-get was supported. |
|
@javanna This might be a bloody stupid question, but: In which way does someone pick up an API and starts working on it? Without risking that someone did the same.: ) |
You add a comment here saying you are working on it. |
|
Thanks @nik9000 ! |
|
I've picked up Create Index. |
|
I have picked up " indices exist". |
|
For questions related to code (how to run a test, which tests are (not) needed, do we need the async version of a method etc.) do I ask here, in a separate issue or the forums? Or something else? : ) |
|
hi @hariso it depends on the question :) Probably better to open a PR even though it is work in progress, so we can discuss your questions there. Would that work for you? |
|
It definitely would. Thanks for the answer! |
Add _open to the high level REST client Relates to #27205
Add _open to the high level REST client Relates to #27205
|
Perhaps another general "java convention" to consider @hub-cap. How do we map potentially long-running I hit this trying to find a long-running task that could be used in my
Does this make sense? It probably applies to more than |
Add `count()` api method, `CountRequest` and `CountResponse` classes to HLRC. Code in server module is unchanged. Relates to #27205
Extend High Level Rest Client Reindex API to support requests with wait_for_completion=false. This method will return a TaskID and results can be queried with Task API refers: elastic#27205
Add `count()` api method, `CountRequest` and `CountResponse` classes to HLRC. Code in server module is unchanged. Relates to #27205
|
@markharwood I think as mentioned above, I dont think throwing exceptions is the way to go, so I dont think we should be removing it from Also, I agree with @pgomulka and your assessment of sync/async/submit, |
relates to elastic#27205
Extend High Level Rest Client Reindex API to support requests with wait_for_completion=false. This method will return a TaskSubmissionResult with task identifier as string and results can be queried with Task API refers: #27205
Extend High Level Rest Client Reindex API to support requests with wait_for_completion=false. This method will return a TaskSubmissionResult with task identifier as string and results can be queried with Task API refers: elastic#27205
Extend High Level Rest Client Reindex API to support requests with wait_for_completion=false. This method will return a TaskSubmissionResult with task identifier as string and results can be queried with Task API refers: elastic#27205
This comment has been minimized.
This comment has been minimized.
|
@utkarsh4G Could you please ask this question on our discuss forum |
|
|
|
Just kidding, closing in favor of #47678 |
and others
This is a meta issue to track completeness of the Java REST high-level Client in terms of supported API. The following list includes all the REST API that Elasticsearch exposes to date, and that are also exposed by the Transport Client. The ones marked as done are already supported by the high-level REST client, while the others need to be added. Every group is sorted based on an estimation around how important the API is, from more important to less important. Each API is also assigned a rank (easy, medium, hard) that expresses how difficult adding support for it is expected to be.
The API listed as "Not Required" won't need to be supported before the transport client is removed from the master branch (next major version). Such API are mainly administrative API that are not likely to be used from a Java application. They generally return heavy responses and make it hard to reuse response objects from the transport client as they expose internal objects that in some cases cannot even be parsed back entirely based on the information returned at REST. We considered returning those as maps of maps but that’s also easy to achieve using the low-level REST client hence we decided to not implement them for the time being.
Top-level APIs
Indices API
[ ] types exist (easy)Not required
Snapshot API
Ingest API
Tasks API
Cluster API
Not required
REST only API
There are a number of API that are exposed via REST but not via the Transport Client. They don't necessarily have to be implemented if the goal is feature parity with the Transport Client, yet we should probably have a look at why they were not added to the Transport Client and whether it makes sense to add their support to the high-level REST Client or not. I don't think it makes sense to add support for cat API and ingest processor grok, hence I took them out already.
ingest processor grokcat API: aliases, allocation, count, fielddata, health, help, indices, master, nodeattrs, nodes, pending tasks, plugins, recovery, repositories, segments, shards, snapshots, tasks, templates, threadpoolHow to add support for a new API
Look at some of the already supported API and existing PRs that have been merged:
The common tasks in each of the above PRs are:
fromXContentmethod to existing response class currently used by transport client and corresponding unit tests that make use of fields shuffling as well as random fields insertion (in order to test forward compatibility). That usually means adding a test for the response object that extendsAbstractXContentTestCasewheresupportsUnknownFields()returns true as well asassertToXContentEquivalence. There are cases where we can't insert random fields everywhere, which then require to also override thegetRandomFieldsExcludeFilter()method which returns path that should be excluded when injecting random fields. Given the randomizations applied, it makes sense to run this type of test locally with-Dtests.iters=50argument just to make sure that it is consistently green.Requestclass which translates the input request into the internal REST request representation that holds method, url, endpoint, params etc. and add corresponding tests toRequestTestsRestHighLevelClient, possibly also its async variant when it makes sense, we may not want to add async variants to every single method, so we decide case by case. The name of the new method must match what is defined in our REST spec including the namespace.ESRestHighLevelClientTestCasethat tests the new method end-to-end by sending REST requests to an external cluster./path/to/elastic/docs/build_docs.pl --doc docs/java-rest/index.asciidoc --chunk 1 --out ~/temp/asciidoc --open. This requires also a local checkout of the docs repository, where the perl script is located.Relates #29827
The text was updated successfully, but these errors were encountered: