This supports runtime injection of Param.Expander. Implementing
contracts will assign `MethodMetadata.indexToExpander` using configured
values. When `MethodMetadata.indexToExpander` is unset, Feign has the
existing behavior, which is to newInstance each `indexToExpanderClass`.
Before this change, if someone accidentally left out the HTTP method in
a `@RequestLine` annotation, they'd get an undecipherable error like:
"Body parameters cannot be used with form parameters." from Contract.java.
This makes the omission easier to find by changing the message to:
"RequestLine annotation didn't start with an HTTP verb..."
Fixes#310
Removing exception wrapping adds flexibility to the interplay of Decoder and ErrorDecoder:
A Decoder can now delegate to an ErrorDecoder and the original ErrorDecoder exception gets
thrown rather than a Feign-specific DecodeException. An example use-case is a Jackson/Gson
implementation of special 404-handling of Optional<Foo> methods: when the Feign client has
decode404() enabled, then the Decoder is in charge of dispatching 404 to Optional#absent
where applicable, or to a delegate ErrorDecoder otherwise; consistent exception handling
requires that the exception produced by the ErrorDecoder does not wrapped.
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
In unsuccessful scenarios, such as redirects, error handling converts a
`Response` into an exception. When a user defines a return type as
`Response`, we can assume they will want access to things like headers
even in an error scenario.
See #249
When log level is full, the response body is rebuffered. The Apache
client had a bug where it allowed `toInputStream` to return null. This
fixes that bug and backfills tests for the other two clients.
Fixes#255
Before this change, apis that follow patterns across a service could
only be modeled by copy/paste/find/replace. Especially with a large
count, this is monotonous and error prone.
This change introduces support for base apis via single-inheritance
interfaces. Users ensure their target interface bind any type variables
and as a result have little effort to create boilerplate apis.
Ex.
```java
@Headers("Accept: application/json")
interface BaseApi<V> {
@RequestLine("GET /api/{key}")
V get(@Param("key") String);
@RequestLine("GET /api")
List<V> list();
@Headers("Content-Type: application/json")
@RequestLine("PUT /api/{key}")
void put(@Param("key") String, V value);
}
interface FooApi extends BaseApi<Foo> { }
interface BarApi extends BaseApi<Bar> { }
```
closes#133
Previously, the Retryer instance provided to the Builder was simply reused, but the instance keeps per-request state, causing repeatable requests to stop being retried. Fixes#236
While encoding or decoding, an exception without a message can occur.
Before this change, a NPE would return as the codec exceptions null
checked the message from the cause.
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.
Feign has `MethodMetadata.bodyType()`, but never passed it to encoders.
Encoders that register type adapters need to do so based on the
interface desired as opposed to the implementation class. This change
breaks api compatibility for < 8.x, by requiring an additional arg
on `Encoder.encode`.
see https://github.com/square/retrofit/issues/713
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
Parameters annotated with `Param` expand based on their `toString`. By
specifying a custom `Param.Expander`, users can control this behavior,
for example formatting dates.
```java
@RequestLine("GET /?since={date}") Result list(@Param(value = "date", expander = DateToMillis.class) Date date);
```
Closes#122
Feign 8.x will no longer support Dagger, nor interfaces annotated with `javax.inject.@Named`. Users must migrate from `javax.inject.@Named` to `feign.@Param` via Feign v7.1+ before attempting to update to Feign 8.0.
For example, the following uses `@Param` as opposed to `@Named` to annotate template parameters.
```java
interface GitHub {
@RequestLine("GET /repos/{owner}/{repo}/contributors")
List<Contributor> contributors(@Param("owner") String owner, @Param("repo") String repo);
}
```
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.