-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
REST Client: Add Request object flavored methods #29623
Conversation
This reverts commit 1cf984f.
The test looks like it is asserting stuff about the request but that duplicates what is in `HighLevelRequestsTests`.
Pinging @elastic/es-core-infra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some comments but they are all minor. LGTM otherwise. I wonder if we should take out the deprecations and include them in a followup PR that can have the deprecation
label and more visibility. Also, this will go 6.x too right?
import java.util.StringJoiner; | ||
|
||
public final class Request { | ||
|
||
final class HighLevelRequests { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ also on the visibility change
import java.util.Objects; | ||
|
||
/** | ||
* Request to Elasticsearch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HTTP request?
private final String method; | ||
private final String endpoint; | ||
|
||
private Map<String, String> parameters = Collections.<String, String>emptyMap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: shall we also make the parameters final? We could expose an add method if we want to rather than set. not too sure myself though about this, do what you prefer, just an idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll check on that!
} catch (Exception e) { | ||
responseListener.onFailure(e); | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we have a small private method that allows to build the request given all the different params and incorporates the catch as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't do that because each method sets different stuff.
assertArrayEquals(headers, request.getHeaders()); | ||
} | ||
|
||
// TODO equals and hashcode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ I have been wondering if we could make add a test dep to our test-framework. I think the reason why we haven't done it before is the java7 requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the java 7 requirement is it I think.
`performRequest` or `performRequestAsync`. `performRequest` is synchronous and | ||
will block the calling thread and return the `Response` when the request is | ||
complete. `performRequestAsync` is asynchronous and accepts a `ResponseListener` | ||
argument that it will call with the request is complete or fails. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this last sentence doesn't compile
callback instance per request attempt. Controls how the response body gets | ||
streamed from a non-blocking HTTP connection on the client side. When not | ||
provided, the default implementation is used which buffers the whole response | ||
body in heap memory, up to 100 MB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
part of this explanation was useful I think, like the explanation of the default limit, which says why you may need to provide your own impl. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added the explanation back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have you removed the link to the HttpAsyncResponseConsumer
javadocs on purpose? You think it was not useful?
import java.util.StringJoiner; | ||
|
||
public final class Request { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more thing, not too convinced about naming, given that what these methods do is convert from high-level requests to low-level requests. maybe rather Requests
or RequestUtils
? not a big deal though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll rename it to RequestConverters
. OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++
@@ -1370,143 +1343,115 @@ private static void assertToXContentBody(ToXContent expectedBody, HttpEntity act | |||
assertEquals(expectedBytes, new BytesArray(EntityUtils.toByteArray(actualEntity))); | |||
} | |||
|
|||
public void testParams() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This behavior has all been migrated to the Request
object and has a test in the low level REST client.
@javanna, I've worked through most of your comments. The one about using a |
In elastic#29623 we added `Request` object flavored requests to the low level REST client and in elastic#30315 we deprecated the old `performRequest`s. This changes all calls in the `x-pack/qa/smoke-test-monitoring-with-watcher`, `x-pack/qa/smoke-test-watcher`, and `x-pack/qa/smoke-test-watcher-with-security` projects to use the new versions.
In #29623 we added `Request` object flavored requests to the low level REST client and in #30315 we deprecated the old `performRequest`s. This changes all calls in the `x-pack/qa/smoke-test-monitoring-with-watcher`, `x-pack/qa/smoke-test-watcher`, and `x-pack/qa/smoke-test-watcher-with-security` projects to use the new versions.
In #29623 we added `Request` object flavored requests to the low level REST client and in #30315 we deprecated the old `performRequest`s. This changes all calls in the `x-pack/qa/smoke-test-monitoring-with-watcher`, `x-pack/qa/smoke-test-watcher`, and `x-pack/qa/smoke-test-watcher-with-security` projects to use the new versions.
In elastic#29623 we added `Request` object flavored requests to the low level REST client and in elastic#30315 we deprecated the old `performRequest`s. This changes all calls in the `x-pack/plugin/ml/qa/native-multi-node-tests`, `x-pack/plugin/ml/qa/single-node-tests` projects to use the new versions.
In elastic#29623 we added `Request` object flavored requests to the low level REST client and in elastic#30315 we deprecated the old `performRequest`s. This changes all calls in the `x-pack/qa/saml-idp-tests` and `x-pack/qa/security-setup-password-tests` projects to use the new versions.
In elastic#29623 we added `Request` object flavored requests to the low level REST client and in elastic#30315 we deprecated the old `performRequest`s. This changes all calls in the `client` and `distribution` projects to use the new versions.
In elastic#29623 we added `Request` object flavored requests to the low level REST client and in elastic#30315 we deprecated the old `performRequest`s. In a long series of PRs I've changed all of the old style requests that I could find with `grep`. In this PR I change all requests that I could find by *removing* the deprecated methods. Since this is a non-trivial change I do not include actually removing the deprecated requests. I'll do that in a follow up. But this should be the last set of usage removals before the actual deprecated method removal. Yay!
In #29623 we added `Request` object flavored requests to the low level REST client and in #30315 we deprecated the old `performRequest`s. In a long series of PRs I've changed all of the old style requests that I could find with `grep`. In this PR I change all requests that I could find by *removing* the deprecated methods. Since this is a non-trivial change I do not include actually removing the deprecated requests. I'll do that in a follow up. But this should be the last set of usage removals before the actual deprecated method removal. Yay!
In elastic#29623 we added `Request` object flavored requests to the low level REST client and in elastic#30315 we deprecated the old `performRequest`s. In a long series of PRs I've changed all of the old style requests. This drops the deprecated methods and will be released with 7.0.
In #29623 we added `Request` object flavored requests to the low level REST client and in #30315 we deprecated the old `performRequest`s. In a long series of PRs I've changed all of the old style requests that I could find with `grep`. In this PR I change all requests that I could find by *removing* the deprecated methods from master. Note: I'm not actually removing all calls to the deprecated methods in ths commit. I'm just backporting the commit from master that removes all of the deprecated calls so future backports from master will be clean. There is *probably* still calls to the deprecated methods in the 6.x branch which is just fine because we'll only be dropping this methods from master.
Adds two new methods to
RestClient
that take aRequest
object. Thesemethods will allows us to add more per-request customizable options
without creating more and more and more overloads of the
performRequest
and
performRequestAsync
methods. These new methods look like:and
This change doesn't add any actual features but enables adding things like
per request timeouts and per request node selectors. This change does
rework the
HighLevelRestClient
and its tests to use these newRequest
objects and it does update the docs.