-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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 REST client guides to use stage.code.quarkus.io instead of restcountries.eu #21166
Conversation
org.acme.restclient.CountriesService: | ||
url: https://restcountries.eu/rest | ||
org.acme.rest.client.ExtensionsService: | ||
url: https://stage.code.quarkus.io/api |
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.
Hmmm, is it a good idea to use a staging instance?
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 was requested - #20810 (comment)
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 can see that :). But I'm not very convinced it's a good idea. @ia3andy don't you think it would be better to use the production API? I don't expect a ton of load and availability is important given you have people from all over the world testing this in different time zones.
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.
staging is as available as production @gsmet
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.
hmm, I don't see that much of a difference. A matter of preference? Let me know if I should change it.
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.
staging is better, it has the same availability, we already have tests using it and most important of all at least it doesn't affect our usage statistics
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.
OK, I'll keep my "I told you so" for later then ;).
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.
Oh that's nasty :)
@michalszynkiewicz can you have a quick look at that given it's about the REST Client? And there's the corresponding quickstart PR here: quarkusio/quarkus-quickstarts#977 . |
---- | ||
which configures our REST client to connect to an SSL REST service. | ||
|
||
For the purposes of this guide, we also need to remove the configuration that starts the embedded WireMock server that stubs REST client responses so the tests actually propagate calls to the https://stage.code.quarkus.io/api. Update the test file `src/test/java/org/acme/rest/client/ExtensionsResourceTest.java` and remove the line: |
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 don't get the motivation for removing wiremock
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.
Wiremock server before this was wrong and propagated actual calls from tests to the restcountries.eu. This native SSL guide relied on this mistake which once fixed couldn't reproduce this issue that this guide was referring to as stubs worked :).
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.
Maybe instead of showing the issue in tests, the guide could just mention that when someone tries it out, it fails?
Removing wiremock seems a bigger change to the project, and might send a message to not mock the API if it's https
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.
Agreed, but I will do that in a subsequent PR. This is exactly why I didn't want to do broader refactoring under the "Update REST client guides..." commits :)
|
||
[source,bash] | ||
---- | ||
./mvnw clean install -Pnative | ||
./mvnw clean install -Pnative -DskipTests |
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.
if wiremock is not removed, there's no need to skip tests
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.
So I have native SSL rework on my TODO list after this but didn't want to have unrelated changes in already bigger PR. The problem is that http://restcountries.eu/rest will respond with 302 Found which will fail the tests. Not sure if that should act as restcountries.eu where I suppose there was a redirect to https variant so the tests passed. A few possible solutions but I'm not sure which one would be the best. Should I adjust rest-client tests to expect either 200 and correct JSONs or 302 and no JSON?
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.
please ping me on Zulip when you get to implement that :)
==== | ||
No `@PathParam` annotation is necessary on `countryName` as the name of the parameter matches the value used in the `@Path` annotation | ||
==== | ||
The `getById` method gives our code the ability to query an extension by id from the Code Quarkus API. The client will handle all the networking and marshalling leaving our code clean of such technical details. |
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.
Maybe:
The `getById` method gives our code the ability to query an extension by id from the Code Quarkus API. The client will handle all the networking and marshalling leaving our code clean of such technical details. | |
The `getById` method gives our code the ability to get an extension by id from the Code Quarkus API. | |
The client will handle all the networking and marshalling leaving our code clean of such technical details. |
@Path("/v2") | ||
public interface CountriesService { | ||
@Path("/extensions") | ||
@RegisterRestClient |
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.
@RegisterRestClient |
@@ -266,18 +252,19 @@ With this approach the client interface could look as follows: | |||
---- | |||
package org.acme.rest.client; | |||
|
|||
import org.eclipse.microprofile.rest.client.inject.RegisterRestClient; |
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.
import org.eclipse.microprofile.rest.client.inject.RegisterRestClient; |
} | ||
---- | ||
|
||
<1> There can be only one `ClientHeadersFactory` per class. With it, you can not only add custom headers, but you can also transform existing ones. See the `RequestUUIDHeaderFactory` class below for an example of the factory. | ||
<2> `@ClientHeaderParam` can be used on the client interface and on methods. It can specify a constant header value... | ||
<3> ... and a name of a method that should compute the value of the header. It can either be a static method or a default method in this interface | ||
<4> ... as well as a value from your application's configuration | ||
<5> ... or as a normal JAX-RS `@HeaderParam` annotated argument |
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.
good catch!
thanks for handling it! The only big issue is the |
By the way, can you squash the commits? |
@michalszynkiewicz thanks for the review. Do you think that squashing is better? Touching multiple QS so I thought it better to split but surely I can squash just please confirm. Native SSL guide will probably need a broader rework which I can do in later PR. |
LGTM, could you squash the commits? |
… of https://restcountries.eu Update native-and-ssl guide to work with https://stage.code.quarkus.io/api Update REST Client reactive guide to work with https://stage.code.quarkus.io/api Update config-yaml guide to work with https://stage.code.quarkus.io/api
Nevermind, just saw you did :) |
Fixes #20810