interface level header defaults

[jdamick]

I implemented an enhanced contract that extends the default contract but adds the ability to set interface level Headers as defaults unless overridden at the method level..

I also added convenience annotations for ContentType & Accept since those (at least in our experience) are most typically set.
The annotations follow more of the jaxrs style, but another option I could see would be adding these as settables in the Feign.Builder when creating the client.. I'm on fence as which one i like better.

Are either of these of interest as a pull? @adriancole

[codefromthecrypt]

Hi, Jeff. Good ideas. One thing I was thinking about was if annotation is the best way for this. Reason being is that it is as you mention a pretty common act. Could RequestInterceptor be a more composable way to accomplish this? I understand the downside is that RequestInterceptor isn't visible in the interface..

…

-A

[codefromthecrypt]

ex. if we baked in a simple default request interceptor which set accept/content-type based on the method (or not) https://github.com/Netflix/feign/blob/master/core/src/test/java/feign/FeignBuilderTest.java#L99

[jdamick]

yeah, that's good too. How would you set the media type for that interceptor?
some like:

Feign.builder().requestInterceptor(new RequestMediaTypeInterceptor("application/json"))

or like

Feign.builder().contentType("application/json") // under the covers add the interceptor?

or did you have something else in mind?

[codefromthecrypt]

I want to be careful about adding too much to the builder. How about something like.. Feign.builder().requestInterceptor(AddMediaTypeHeaders.APPLICATION_JSON) which is a constant.. or heck you could even make the thing an enum :) at any rate, should be easy to apply json and xml

[jdamick]

I linked to a commit ^ - before i spend too much more time i wanted to see if this was more inline.. (i'm sure some naming might need tweaking)

[codefromthecrypt]

Looks good! One nit would be to adjust the javadoc on Headers to suggest that they are additive, so don't place anything on the type that isn't meant for all methods. That and a test case that shows this. (ex. adding the same header twice = 2 values). Good job, Jeff!

[codefromthecrypt]

oof.. @jdamick we have a hitch. My intention is that 8.x is feature compatible with 7.x. That way, folks can migrate cleanly off dagger via the 7-8 bridge. Also, Spring implement Contract. We probably want to avoid changing the Contract interface as a part of this change.

What that means is that we'd need some logic to reach up to the type in parseAndValidatateMetadata to find the base headers. Ex.

Headers fromType = method.getDeclaringClass().getAnnotation(Headers.class);

Ack that is more expensive than your approach. Wdyt about saving Contract interface refactors for when we bang our heads around hystrix/rxnetty?

[jdamick]

I have no burning need for it at the moment, so i'm fine with waiting until 9.

[codefromthecrypt]

added to 7.4/8.1 release after realizing a simple way to accomplish this portably.