Ich bin verantwortlich für ein Projekt, das die API-API-Kooperationsverarbeitung mit einem externen Dienst realisiert. Notieren Sie sich die verschiedenen Recherchen / Umsetzungen des Titels.
Die verantwortliche Person auf der externen Service-Seite sagte Folgendes.
Als Antwort auf das oben Gesagte habe ich beim Entwerfen der API auf dieser Seite über Folgendes nachgedacht.
Wenn ich das oben genannte mache, frage ich mich, ob es den Anforderungen externer Dienste gerecht wird. Auch hier ist es einfacher, das zurückzugeben, was Sie zuerst zurückgeben. Das Codebild ist unten.
SampleController.java
@RestController
public class SampleController() {
//Anfragen von externen Diensten annehmen
@RequestMapping(value = "/sample")
public String sample(@Validated SampleForm form) {
//Minimale Verarbeitung, um eine Antwort zurückzugeben
return "";
}
//Nachbearbeitung(Bild: Wenn Sie diesen Artikel lesen, wird er nicht so implementiert)
private void after() {
//Die Verarbeitung ist erforderlich, außer dass eine Antwort zurückgegeben wird
}
}
Nach der Untersuchung scheint es, dass es durch "HandlerInterceptor # afterCompletion ()" realisiert werden kann. Ich habe auf den folgenden Artikel verwiesen. Grundlegendes zum Implementieren der allgemeinen Anforderungsverarbeitung in Spring MVC (+ Spring Boot)
HandlerInterceptor ist eine Schnittstelle, die auch Methoden für andere Zwecke als die Nachbearbeitung enthält.
Dieses Mal möchte ich also nur die Nachbearbeitung einzeln implementieren
Bereiten Sie eine Klasse vor, die "HandlerInterceptorAdapter" erbt. Dies ist eine Implementierungsklasse von "HandlerInterceptor".
Aus Sicht der Nachbearbeitung ist "HandlerInterceptor # postHandle ()" ebenfalls ein Kandidat.
Dies ist ausgeschlossen, da es nicht unseren Anforderungen entspricht, da es nicht aufgerufen wird, wenn eine Ausnahme auftritt.
HandlerInterceptor # afterCompletion () wird aufgerufen, unabhängig davon, ob es normal endet oder eine Ausnahme auftritt.
SampleInterceptor.java
public class SampleInterceptor extends HandlerInterceptorAdapter {
//Am Ende des Normalen/AfterCompletion, da ich unabhängig von einer abnormalen Beendigung nur die Nachbearbeitung implementieren möchte()Nur überschreiben
@override
public void afterCompletion(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex) throws Exception {
//Implementierung nach der Verarbeitung
}
}
Als nächstes besteht unsere Anforderung darin, die Nachbearbeitung nur auf Anforderungen für "/ sample" im obigen Codebild anzuwenden. Dies kann mit der folgenden Implementierung behoben werden, die auch im obigen Artikel erwähnt wird.
WebMvcConfig.java
@Configuration
public class WebMvcConfig extends WebMvcConfigurerAdapter {
//Ich muss die Bohne registrieren
@Bean
public SampleInterceptor sampleInterceptor() {
return new SampleInterceptor();
}
@Bean
public HogeInterceptor hogeInterceptor() {
return new HogeInterceptor();
}
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(sampleInterceptor())
.addPathPatterns("/sample"); //Das Ziel wird hier angegeben
//Wenn Sie mehrere Interceptors angeben möchten, schreiben Sie diese nebeneinander. Sie können auch mehrere Pfade verketten und angeben
registry.addInterceptor(hogeInterceptor())
.addPathPatterns("/hoge").addPathPatterns("/huga")
//Wenn Sie denselben Pfad in verschiedenen Interceptors angeben, beide afterCompletions()Wird ausgeführt
//Es wurde nicht untersucht, wie die Ausführungsreihenfolge entschieden wird
.addPathPatterns("/sample");
}
}
Mit dem Obigen wurde die erforderliche Verarbeitung realisiert.
Wenn Sie mit addPathPatterns kein Ziel angeben, scheinen alle Controller einer Nachbearbeitung zu unterliegen.
Der eigentliche Code ist nicht auf den obigen Beispielcode beschränkt, es gibt jedoch noch einige weitere. Das ist alles, was ich aufschreiben möchte.
Recommended Posts