Skip to content
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

Merged
merged 3 commits into from
Mar 6, 2020
Merged

Conversation

carterkozak
Copy link
Contributor

==COMMIT_MSG==
Support weighted encodings for Accept type preference.
==COMMIT_MSG==

@changelog-app
Copy link

changelog-app bot commented Mar 5, 2020

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Support weighted encodings for Accept type preference.

Check the box to generate changelog(s)

  • Generate changelog entry

* Note that the weight may not be applied to the Accept header, rather
* used to order values.
*/
final class WeightedEncoding {
Copy link
Contributor Author

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
Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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 ¯_(ツ)_/¯

Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@ferozco
Copy link
Contributor

ferozco commented Mar 6, 2020

👍

@bulldozer-bot bulldozer-bot bot merged commit 8a7a9d3 into develop Mar 6, 2020
@bulldozer-bot bulldozer-bot bot deleted the ckozak/support_weighted_encodings branch March 6, 2020 00:38
@svc-autorelease
Copy link
Collaborator

Released 0.15.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants