* Refactoring RequestTemplate to RFC6570
This change refactors `RequestTemplate` in an attempt to
adhere to the [RFC-6570 - URI Template](https://tools.ietf.org/html/rfc6570)
specification more closely. The reason for this is to
reduce the amount of inconsistency between `@Param`, `@QueryMap`,
`@Header`, `@HeaderMap`, and `@Body` template expansion.
First, `RequestTemplate` now delegates uri, header, query, and
body template parsing to `UriTemplate`, `HeaderTemplate`,
`QueryTemplate`, and `BodyTemplate` respectively. These components
are all variations on a `Template`.
`UriTemplate` adheres to RFC 6570 explicitly and supports Level 1
(Simple String) variable expansion. Unresolved variables are ignored
and removed from the uri. This includes query parameter pairs. All
literal and expanded variables are pct-encoded according to the Charset
provided in the `RequestTemplate`.
`HeaderTemplate` supports Level 1 (Simple String) variable expansion.
Unresolved variables are ignored. Empty headers are removed. No
encoding is performed.
`QueryTemplate` is a subset of a `UriTemplate` and reacts in the same
way. Unresolved pairs are ignored and not present on the final
template. All literals and expanded variables are pct-encoded
according to the Charset provided.
`BodyTemplate` supports Level 1 (Simple String) variable expansion.
Unresolved variables produce empty strings. Values are not encoded.
All remaining customizations, including custom encoders, collection format
expansion and charset encoding are still supportted and made backward
compatible.
Finally, a number of inconsistent methods on `RequestTemplate` have
been deprecated for public use and all deprecated usage throughout
the library has been replaced.
Closes#719
This change adds the original Request Method to `RetryableException`,
allowing implementers to determine if a retry should occur based on
method and exception type.
To support this, `Response` objects now require that the original
`Request` be present. Test Cases, benchmarks, and documentation have
been added.
* Refactored Request Method Attribute on Requests
* Added `HttpMethod` enum that represents the supported HTTP methods
replacing String handling.
* Deprecated `Request#method()` in favor of `Request#httpMethod()`
This adds the `Feign.Builder.decode404()` flag which indicates decoders
should process responses with 404 status. It also changes all
first-party decoders (like gson) to return well-known empty values by
default. Further customization is possible by wrapping or creating a
custom decoder.
Prior to this change, we used custom invocation handlers as the way to
add fallback values based on exception or return status. `feign-hystrix`
uses this to return `HystrixCommand<X>`, but the general pattern applies
to anything that has a type representing both success and failure, such
as `Try<X>` or `Observable<X>`.
As we define it here, 404 status is not a retry or fallback policy, it
is just empty semantics. By limiting Feign's special processing to 404,
we gain a lot with very little supporting code.
If instead we opened all codes, Feign could easily turn bad request,
redirect, or server errors silently to null. This sort of configuration
issue is hard to troubleshoot. 404 -> empty is a very safe policy vs
all codes.
Moreover, we don't create a cliff, where folks seeking fallback policy
eventually realize they can't if only given a response code. Fallback
systems like Hystrix address exceptions that occur before or in lieu of
a response. By special-casing 404, we avoid a slippery slope of half-
implementing Hystrix.
Finally, 404 handling has been commonly requested: it has a clear use-
case, and through that value. This design supports that without breaking
compatibility, or impacting existing integrations such as Hystrix or
Ribbon.
See #238#287
Files had various formatting differences, as did pull requests. Rather than
create our own style, this inherits and requires the well documented Google
Java Style.
Dagger 1.x and 2.x are incompatible. Rather than choose one over the
other, this change removes Dagger completely. Users can now choose any
injector, constructing Feign via its Builder.
This change also drops support for javax.inject.Named, which has
been replaced by feign.Param.
see #120
AssertJ has more powerful test assertions and does not run the risk of
interfering with the classpath of main code, such as guava does. This
removes guava from test and example code and adjusts using AssertJ in
some cases.
JUnit Rules, such as MockWebServerRule, reduce boilerplate setup present
in our tests. By migrating off TestNG, and onto rules, our tests become
more maintainable as JUnit is well understood.
Request/Response/RequestTemplate are now fundamentally based on a byte[] body field.
For Request/RequestTemplate, if a charset is provided, it can be treated as text.
For many users of the library, the change should barely be noticeable, as the methods that
were changed were mostly used internally.
There were some non-backwards-compatible signature changes that require a
major version bump, however.
Kevin Davis
adriancole
Marvin Froeder
Marvin Herman Froeder
Benjamin Shai
Merkushev Kirill
Nick Fiacco
Adrian Cole
Gursev Singh Kalra
Adrian Cole
Rob Spieldenner
David M. Carr