-
Notifications
You must be signed in to change notification settings - Fork 16
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
Support weighted encodings #493
Conversation
Generate changelog in
|
* Note that the weight may not be applied to the Accept header, rather | ||
* used to order values. | ||
*/ | ||
final class WeightedEncoding { |
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.
initially this was public, but the API feels a lot cleaner exposing a builder method overload with weight.
@@ -50,30 +53,36 @@ | |||
* {@link Encoding#supportsContentType supports} the serialization format {@link HttpHeaders#ACCEPT accepted} | |||
* by a given request, or the first serializer if no such serializer can be found. | |||
*/ | |||
ConjureBodySerDe(List<Encoding> encodings) { | |||
// TODO(jellis): consider supporting cbor encoded errors |
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.
Removed this todo, a while ago we discussed content-type negotiation and agreed that failures should always use the most basic encoding, that way if bugs are introduced we have the best shot at understanding what is going wrong.
* Note that the weight may not be applied to the Accept header, rather | ||
* used to order values. | ||
*/ | ||
final class WeightedEncoding { |
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.
might be simpler to use an immutable?
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 could go either way, we don't use annotation processors in this module yet. I tend to avoid immutables for fewer than three parameters ¯_(ツ)_/¯
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.
fair, I lean towards immutables for consistency with other data classes and to reduce boilerplate
|
||
/** | ||
* Represents an encoding with a weight for <code>Accept</code> types. | ||
* Note that the weight may not be applied to the Accept header, rather |
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.
Why lock ourselves out from applying q-factor to accept headers?
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.
My goal was to make it clear that it doesn't necessarily use q-factor values, but could in the future.
...ogue-serde/src/main/java/com/palantir/conjure/java/dialogue/serde/DefaultConjureRuntime.java
Outdated
Show resolved
Hide resolved
👍 |
Released 0.15.1 |
==COMMIT_MSG==
Support weighted encodings for
Accept
type preference.==COMMIT_MSG==