Feign (dept44-starter-feign)

Denna starter förenklar användningen av Feign som REST-klient, via Spring Cloud OpenFeign. För att använda den, lägg till följande i tjänstens pom.xml:

<dependency>
	<groupId>se.sundsvall.dept44</groupId>
	<artifactId>dept44-starter-feign</artifactId>
</dependency>

Lägg även till annoteringen @EnableFeignClients på main-klassen.

Alternativ 1 - FeignMultiCustomizer

FeignMultiCustomizer är en ersättare för den utfasade klassen FeignBuilder, beskriven under alternativ 2. Den är en hjälpklass för att bygga REST-klienter med hjälp av interface som annoteras med Spring:s annoteringar för request-mappning, t.ex.:

@FeignClient(name = "GithubClient", 
             url = "${integration.github.url}", 
             configuration = GithubConfiguration.class)
public interface GithubClient {

    @GetMapping("/{user}?tab=repositories", produces = APPLICATION_JSON_VALUE)
    List<Repo> getRepositoriesForUser(@PathVariable("user") String user);
}

Med hjälp av klassen FeignMultiCustomizer genereras en böna som kedjar ihop flera FeignBuilderCustomizer till en, som sedan används när klienten skapas. Värt att notera är att FeignBuilderCustomizer kan blandas med bönor som plockas upp av feign (se alternativ 3) så länge de två alternativen inte krockar med varandra.

@Import(FeignConfiguration.class)										[1]
public class GithubConfiguration {

	@Bean
	FeignBuilderCustomizer feignBuilderCustomizer() {
		return FeignMultiCustomizer.create()
			.withCustomizer(...)										[2]
			.withErrorDecoder(...)										[3]
			.withRequestInterceptor(...)								[4]
			.withRequestOptions(...)									[5]
			.withRequestTimeoutsInSeconds(...)							[6]
			.withRetryableOAuth2InterceptorForClientRegistration(...)	[7]
			.composeCustomizersToOne();									[8]
	}
}

Interfacet kan sedan användas för att anropa integrationer i andra klasser:

[1] Ifall FeignConfiguration från Dept-44 importeras så läggs funktionalitet för loggning av request och response, requestId-hantering samt hantering av truststore för domän sundsvall.se (för hantering av anrop mot andra mikrotjänster i WSO2) till.
[2] Möjliggör ytterligare anpassning av Feign-klienten i de fall stöd saknas i ramverket.
[3] Anger den error decoder som ska användas för att översätta de fel som kastas av integrationen.
[4] Anger de interceptorer som ska användas för att förändra det utgående anropet före det skickas.
[5] Anger de anrops-alternativ som ska gälla för klienten avseende timeouts och follow-redirects
[6] En alternativ metod till [5] där follow-redirects default sätts till true
[7] Anger att ett nytt anrop med förnyat access token ska ske ifall autentiseringsuppgifterna har gått ut.
[8] Skapar den FeignBuilderCustomizer som sedan används av OpenFeign-ramverket när klienten skapas.

([4] kan användas repetitivt för all lägga till multipla RequestInterceptor).

Alternativ 2 - Annoteringar

Först och främst behövs ett klient-interface:

[1] Anger namn på Feign-klienten
[2] Anger bas-URL för klienten. Kan utgöras av Spring EL-uttryck/properties, t.ex. från konfiguration (t.ex. "${some.url}")
[3] Anger en konfigurationsklass för klienten - en vanlig Spring-konfiguration där alla ingående bönor används för att konfigurera klienten.

Exempel på klient-konfiguration:

Ifall konfigurationen definierar någon böna av typen RequestInterceptor, likt [1], kommer den automatiskt att knytas in i Feign-klienten. I exemplet används en utility-klass från ramverket - FeignHelper - för att skapa en interceptor för Basic-autentisering. FeignHelper har även stöd för att jacka in exempelvis en interceptor för OAuth2 och för att anpassa timeouts likt [2].

I exemplet ovan knyts även en generisk ErrorDecoder in i Feign-klienten [3]. Detta är allt som krävs för att klienten skall kunna hantera error-response av Problem-typ (läs mer i befintlig RFC).

Utifrån ovan kan sedan klienten @Autowire:as in som en vanlig Spring-komponent där den behövs:

Generisk ErrorDecoder

Ramverket erbjuder en generisk ErrorDecoder. D.v.s. en mappning mellan “error-response” från tjänsten som anropas och exceptions i den egna tjänsten.

Genom att använda ProblemErrorDecoder eller JsonPathErrorDecoder behöver man inte implementera en egen. Har anropad tjänst implementerat felhantering enligt RFC 7807: Problem Details for HTTP APIs behöver man inte göra någonting mer än att skapa ProblemErrorDecoder bönan i sin konfigurationsklass (se första exemplet nedan).

Om anropad tjänst däremot har uppfunnit en egen modell för fel, kan man behöva peka ut den data man vill mappa med hjälp av klassen JsonPathErrorDecoder och JSON-path.

Konfiguration som krävs när anropad tjänst implementerat RFC-7807:

Konfiguration för fel som avviker från ovan beskriven standard. Genom använda JsonPathErrorDecoder och ange sökvägen via JSON-path till den data vi vill mappa kan vi hantera vilka strukturer på felmeddelandet som helst. Se exempel nedan:

Error-response:

Konfiguration: