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

Java high-level REST client completeness for xpack APIs #29827

Closed
98 tasks done
elasticmachine opened this issue Nov 2, 2017 · 13 comments
Closed
98 tasks done

Java high-level REST client completeness for xpack APIs #29827

elasticmachine opened this issue Nov 2, 2017 · 13 comments
Labels

Comments

@elasticmachine
Copy link
Collaborator

elasticmachine commented Nov 2, 2017

Original comment by @javanna:

This is the xpack side of #27205 . This is a meta issue to track completeness of the Java REST high-level Client in terms of supported xpack API. The following list includes all the REST API that xpack 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 from 1 to 3 that expresses how difficult adding support for it is expected to be.

Please Note The existing actions are in x-pack/ which is governed by the Elastic License, not the Apache License. Engineers who take these should strive to pull the Actions into Apache License controlled territory, so the high level rest client does not use any Elastic License bits. These should live in x-pack/protocol, which is OSS.

Please also note The APIs themselves should follow the spec for how they are named. This means they should be in the XPackClient, not the HighLevelRestClient. This would mean you end up with hlRestClient.xpack().watcher() as an example

Please Please also also note Prepend your commit msgs with HLRC:

Watcher API

Machine Learning API

Machine Learning REST only API

Security API

Security REST only API

Miscellaneous API

Graph API

Licensing API

Rollup

Migration

Monitoring API

  • monitoring bulk

Index Lifecycle Management

See #33100

CCR

See #33824

@elasticmachine
Copy link
Collaborator Author

Original comment by @pickypg:

The _xpack/monitoring/_bulk API is not intended to be supported by outside clients. Its use is only meant for Kibana, Beats, APM Server, and Logstash.

Ideally we will even be removing it once we get to Metricbeat-based monitoring data.

@elasticmachine
Copy link
Collaborator Author

Original comment by @javanna:

thanks for clarifying @pickypg !

@elasticmachine
Copy link
Collaborator Author

Original comment by @tvernum:

@javanna What does

Security Transport Client only API

mean - is that intending to say that there is no REST interface, in which case has privileges is handled by rest action RestHasPrivilegesAction

@elasticmachine
Copy link
Collaborator Author

Original comment by @javanna:

@tvernum I couldn't find the corresponding REST action for some reason. I am going to edit the description and move has privileges with the other API.

@elasticmachine
Copy link
Collaborator Author

Original comment by @javanna:

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.

@elasticmachine
Copy link
Collaborator Author

Original comment by @tvernum:

@javanna Did you have a plan about how we'd ship an X-Pack enabled client?
From the javadocs on the existing OSS client, it seems like the best course of action is a single

public class RestXPackClient extends RestHighLevelClient {

But there's options to have separate clients per feature (I can't see a reason to do that) or to take the same approach as the current SecurityClient and wrap rather than extend the RestHighLevelClient.

@elasticmachine
Copy link
Collaborator Author

Original comment by @javanna:

@tvernum I envisioned extending like you mentioned above, wrapping is an option too though. I don't have a strong opinion, we should give it a try and see how things look.

@nik9000 nik9000 changed the title Java high-level REST client completeness Java high-level REST client completeness for xpack APIs May 9, 2018
nik9000 added a commit to nik9000/elasticsearch that referenced this issue Jul 9, 2018
The `:x-pack:protocol` project is an implementation detail shared by the
xpack projects and the high level rest client and really doesn't deserve
its own maven coordinants and published javadoc. This change bundles
`:x-pack:protocol` into the high level rest client.

Relates to elastic#29827
@nik9000
Copy link
Member

nik9000 commented Jul 9, 2018

One down!

nik9000 added a commit that referenced this issue Jul 10, 2018
The `:x-pack:protocol` project is an implementation detail shared by the
xpack projects and the high level rest client and really doesn't deserve
its own maven coordinants and published javadoc. This change bundles
`:x-pack:protocol` into the high level rest client.

Relates to #29827
nik9000 added a commit that referenced this issue Jul 11, 2018
The `:x-pack:protocol` project is an implementation detail shared by the
xpack projects and the high level rest client and really doesn't deserve
its own maven coordinants and published javadoc. This change bundles
`:x-pack:protocol` into the high level rest client.

Relates to #29827
spinscale added a commit to spinscale/elasticsearch that referenced this issue Jul 13, 2018
spinscale added a commit that referenced this issue Jul 19, 2018
Relates #29827

This implementation behaves like the current transport client, that you basically cannot configure a Watch POJO representation as an argument to the put watch API, but only a bytes reference. You can use the the `WatchSourceBuilder` from the `org.elasticsearch.plugin:x-pack-core` dependency to build watches.

This commit also changes the license type to trial, so that watcher is available in high level rest client tests.

/cc @hub-cap
spinscale added a commit to spinscale/elasticsearch that referenced this issue Jul 19, 2018
Relates elastic#29827

This implementation behaves like the current transport client, that you basically cannot configure a Watch POJO representation as an argument to the put watch API, but only a bytes reference. You can use the the `WatchSourceBuilder` from the `org.elasticsearch.plugin:x-pack-core` dependency to build watches.

This commit also changes the license type to trial, so that watcher is available in high level rest client tests.
imotov added a commit to imotov/elasticsearch that referenced this issue Jul 19, 2018
spinscale added a commit that referenced this issue Jul 24, 2018
Relates #29827

This implementation behaves like the current transport client, that you basically cannot configure a Watch POJO representation as an argument to the put watch API, but only a bytes reference. You can use the the `WatchSourceBuilder` from the `org.elasticsearch.plugin:x-pack-core` dependency to build watches.

This commit also changes the license type to trial, so that watcher is available in high level rest client tests.
jaymode added a commit to jaymode/elasticsearch that referenced this issue Jul 24, 2018
This commit adds a security client to the high level rest client, which
includes an implementation for the put user api. As part of these
changes, the request and response classes were moved to the x-pack
protocol project and licensed under the Apache 2 license.

The PutUserRequest previously performed some validation of the username
that really is more fitting for the server validation. This validation
has been removed to reduce the amount of logic on the client side and
also reduce the number of classes that would need to be moved to the
protocol project. The removed validation now happens in the transport
action.

See elastic#29827
jkakavas added a commit that referenced this issue Nov 21, 2018
This commits adds support for the Get Application Privileges
API to the HLRC

Relates: #29827
jkakavas added a commit that referenced this issue Nov 21, 2018
This commits adds support for the Get Application Privileges
API to the HLRC

Relates: #29827
droberts195 added a commit to droberts195/elasticsearch that referenced this issue Nov 22, 2018
droberts195 added a commit that referenced this issue Nov 23, 2018
droberts195 added a commit that referenced this issue Nov 23, 2018
jkakavas added a commit that referenced this issue Nov 26, 2018
This commits adds support for the Get Roles API to the HLRC

Relates: #29827
jkakavas added a commit that referenced this issue Nov 26, 2018
This commits adds support for the Get Roles API to the HLRC

Relates: #29827
edsavage added a commit to edsavage/elasticsearch that referenced this issue Nov 26, 2018
edsavage added a commit that referenced this issue Nov 26, 2018
edsavage added a commit that referenced this issue Nov 26, 2018
droberts195 pushed a commit that referenced this issue Nov 28, 2018
droberts195 pushed a commit that referenced this issue Nov 28, 2018
iverase added a commit that referenced this issue Nov 29, 2018
* HLRC: Add delete user action

It adds delete user action to the high level rest client.

Relates #29827
iverase added a commit that referenced this issue Nov 29, 2018
* HLRC: Add delete user action

It adds delete user action to the high level rest client.

Relates #29827
hub-cap added a commit to hub-cap/elasticsearch that referenced this issue Dec 5, 2018
This commit adds the Get Deprecation Info API and associated
documentation.

Relates elastic#29827
nik9000 added a commit to nik9000/elasticsearch that referenced this issue Dec 6, 2018
hub-cap added a commit that referenced this issue Dec 7, 2018
This commit adds the Get Deprecation Info API and associated
documentation.

Relates #29827
hub-cap added a commit that referenced this issue Dec 7, 2018
This commit adds the Get Deprecation Info API and associated
documentation.

Note: This commit is different from master as it adds back the
_xpack portion of the API.

Relates #29827
nik9000 added a commit that referenced this issue Dec 7, 2018
nik9000 added a commit that referenced this issue Dec 8, 2018
@hub-cap hub-cap closed this as completed Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants