How to implement declarative HTTP clients with many optional parameters in Micronaut?
I would like to use Micronaut's declarative HTTP client to interact with a REST API having many optional query parameters in its GET methods.
Example: There is an API to GET alarms where what alarms are returned is specified as query parameters. I could use the API with the following method:
@Client("/alarm/alarms")
public interface AlarmApi {
@Get
Single<Alarms> getAlarms(Optional<String> source, Optional<OffsetDateTime> from, Option<OffsetDateTime> to, Optional<Status> status, Optional<Severity> severity, Optional<Integer> pageSize, Optional<Boolean> order);
and query it using
alarms = alarmApi.getAlarms(source, Optional.empty(), Optional.empty(), Optional.empty(), Optional.empty(), Optional.of(2000), Optional.empty());
which is not easy to use. Better (IMHO) would be to have something like
alarm = alarmApi.getAlarms().source(source).pageSize(2000);
Is there a way to do something like this "out of the box" with Micronaut's declarative client?
rest micronaut
add a comment |
I would like to use Micronaut's declarative HTTP client to interact with a REST API having many optional query parameters in its GET methods.
Example: There is an API to GET alarms where what alarms are returned is specified as query parameters. I could use the API with the following method:
@Client("/alarm/alarms")
public interface AlarmApi {
@Get
Single<Alarms> getAlarms(Optional<String> source, Optional<OffsetDateTime> from, Option<OffsetDateTime> to, Optional<Status> status, Optional<Severity> severity, Optional<Integer> pageSize, Optional<Boolean> order);
and query it using
alarms = alarmApi.getAlarms(source, Optional.empty(), Optional.empty(), Optional.empty(), Optional.empty(), Optional.of(2000), Optional.empty());
which is not easy to use. Better (IMHO) would be to have something like
alarm = alarmApi.getAlarms().source(source).pageSize(2000);
Is there a way to do something like this "out of the box" with Micronaut's declarative client?
rest micronaut
You said "I would prefer to use a builder-style approach" and then said "outside of wrapping the declarative API with a builder". You do or do not want to use a builder approach?
– Jeff Scott Brown
Dec 31 '18 at 16:58
I do want to use a builder approach, sorry for misleading phrasing. I edited the question to be hopefully more clear.
– André
Jan 1 at 18:20
In Kotlin you could use the default values and have clear calls by named parameters. In java you could build that yourself, but as your default is Optional.empty anyway why not use a request Object and have there an autogenerated builder that is used to call the method kind of wrapped?
– rom
Feb 14 at 10:34
add a comment |
I would like to use Micronaut's declarative HTTP client to interact with a REST API having many optional query parameters in its GET methods.
Example: There is an API to GET alarms where what alarms are returned is specified as query parameters. I could use the API with the following method:
@Client("/alarm/alarms")
public interface AlarmApi {
@Get
Single<Alarms> getAlarms(Optional<String> source, Optional<OffsetDateTime> from, Option<OffsetDateTime> to, Optional<Status> status, Optional<Severity> severity, Optional<Integer> pageSize, Optional<Boolean> order);
and query it using
alarms = alarmApi.getAlarms(source, Optional.empty(), Optional.empty(), Optional.empty(), Optional.empty(), Optional.of(2000), Optional.empty());
which is not easy to use. Better (IMHO) would be to have something like
alarm = alarmApi.getAlarms().source(source).pageSize(2000);
Is there a way to do something like this "out of the box" with Micronaut's declarative client?
rest micronaut
I would like to use Micronaut's declarative HTTP client to interact with a REST API having many optional query parameters in its GET methods.
Example: There is an API to GET alarms where what alarms are returned is specified as query parameters. I could use the API with the following method:
@Client("/alarm/alarms")
public interface AlarmApi {
@Get
Single<Alarms> getAlarms(Optional<String> source, Optional<OffsetDateTime> from, Option<OffsetDateTime> to, Optional<Status> status, Optional<Severity> severity, Optional<Integer> pageSize, Optional<Boolean> order);
and query it using
alarms = alarmApi.getAlarms(source, Optional.empty(), Optional.empty(), Optional.empty(), Optional.empty(), Optional.of(2000), Optional.empty());
which is not easy to use. Better (IMHO) would be to have something like
alarm = alarmApi.getAlarms().source(source).pageSize(2000);
Is there a way to do something like this "out of the box" with Micronaut's declarative client?
rest micronaut
rest micronaut
edited Jan 2 at 8:54


Naveen Nelamali
350113
350113
asked Dec 29 '18 at 13:53


AndréAndré
56649
56649
You said "I would prefer to use a builder-style approach" and then said "outside of wrapping the declarative API with a builder". You do or do not want to use a builder approach?
– Jeff Scott Brown
Dec 31 '18 at 16:58
I do want to use a builder approach, sorry for misleading phrasing. I edited the question to be hopefully more clear.
– André
Jan 1 at 18:20
In Kotlin you could use the default values and have clear calls by named parameters. In java you could build that yourself, but as your default is Optional.empty anyway why not use a request Object and have there an autogenerated builder that is used to call the method kind of wrapped?
– rom
Feb 14 at 10:34
add a comment |
You said "I would prefer to use a builder-style approach" and then said "outside of wrapping the declarative API with a builder". You do or do not want to use a builder approach?
– Jeff Scott Brown
Dec 31 '18 at 16:58
I do want to use a builder approach, sorry for misleading phrasing. I edited the question to be hopefully more clear.
– André
Jan 1 at 18:20
In Kotlin you could use the default values and have clear calls by named parameters. In java you could build that yourself, but as your default is Optional.empty anyway why not use a request Object and have there an autogenerated builder that is used to call the method kind of wrapped?
– rom
Feb 14 at 10:34
You said "I would prefer to use a builder-style approach" and then said "outside of wrapping the declarative API with a builder". You do or do not want to use a builder approach?
– Jeff Scott Brown
Dec 31 '18 at 16:58
You said "I would prefer to use a builder-style approach" and then said "outside of wrapping the declarative API with a builder". You do or do not want to use a builder approach?
– Jeff Scott Brown
Dec 31 '18 at 16:58
I do want to use a builder approach, sorry for misleading phrasing. I edited the question to be hopefully more clear.
– André
Jan 1 at 18:20
I do want to use a builder approach, sorry for misleading phrasing. I edited the question to be hopefully more clear.
– André
Jan 1 at 18:20
In Kotlin you could use the default values and have clear calls by named parameters. In java you could build that yourself, but as your default is Optional.empty anyway why not use a request Object and have there an autogenerated builder that is used to call the method kind of wrapped?
– rom
Feb 14 at 10:34
In Kotlin you could use the default values and have clear calls by named parameters. In java you could build that yourself, but as your default is Optional.empty anyway why not use a request Object and have there an autogenerated builder that is used to call the method kind of wrapped?
– rom
Feb 14 at 10:34
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53970193%2fhow-to-implement-declarative-http-clients-with-many-optional-parameters-in-micro%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53970193%2fhow-to-implement-declarative-http-clients-with-many-optional-parameters-in-micro%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You said "I would prefer to use a builder-style approach" and then said "outside of wrapping the declarative API with a builder". You do or do not want to use a builder approach?
– Jeff Scott Brown
Dec 31 '18 at 16:58
I do want to use a builder approach, sorry for misleading phrasing. I edited the question to be hopefully more clear.
– André
Jan 1 at 18:20
In Kotlin you could use the default values and have clear calls by named parameters. In java you could build that yourself, but as your default is Optional.empty anyway why not use a request Object and have there an autogenerated builder that is used to call the method kind of wrapped?
– rom
Feb 14 at 10:34