You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like HttpRequest.expect(), but inverted, for conditions that would fail the request if met, allowing to set general fail reasons. This should allow to have a more broad “allowed” request result by setting explicit reject() reasons, thus possibly making the code more readable and easier to understand
Can also be named refuse
Use cases
Implementation wise ResponsePredicate can be reused for this aswell for the reject handling
Basic use
client.getAbs(request)
.as(BodyCodec.jsonObject())
.expect(ResponsePredicate.SOME_STATUS)
.reject(req -> req.headers.contains("bad header"))
.send()
.onFailure(v -> {
System.out.println("I fail if i have `bad header`");
})
Another behavior where specific status code ranges are accepected, opposed to setting multiple expect(), could be done with one reject()
In a scenario where SC_SUCCESS is fine, but TOO_MANY_REQUESTS would benefit from its own exception message
client.getAbs(request)
.as(BodyCodec.jsonObject())
.expect(ResponsePredicate.SOME_STATUS)
.reject(req -> req.status == 429, RatelimitException)
.send()
.onFailure(v -> {
System.out.println("I fail if i have `bad header`");
}).recover(ex -> {
//more clear error message, isntead of relying on String parsing via ErrorConverter or other means
});
Contribution
Can implement myself.
The text was updated successfully, but these errors were encountered:
Describe the feature
Like
HttpRequest.expect()
, but inverted, for conditions that would fail the request if met, allowing to set general fail reasons. This should allow to have a more broad “allowed” request result by setting explicitreject()
reasons, thus possibly making the code more readable and easier to understandCan also be named
refuse
Use cases
Implementation wise ResponsePredicate can be reused for this aswell for the reject handling
Basic use
Another behavior where specific status code ranges are accepected, opposed to setting multiple
expect()
, could be done with onereject()
In a scenario where SC_SUCCESS is fine, but TOO_MANY_REQUESTS would benefit from its own exception message
Contribution
Can implement myself.
The text was updated successfully, but these errors were encountered: