How to implement declarative HTTP clients with many optional parameters in Micronaut?












2















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?










share|improve this question

























  • 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
















2















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?










share|improve this question

























  • 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














2












2








2








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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












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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

MongoDB - Not Authorized To Execute Command

Npm cannot find a required file even through it is in the searched directory

in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith