Warum schlechte Unterstützung für http-Cache-Steuerelement in Spring MVC?

Lesen Sie das Buch REST practice und erhalten Sie ein besseres Verständnis der Web-Scale-out-Basis auf dem Cache. Aber wenn ich versuche, http-Cache-Kontrolle in meinem Spring-Boot-Projekt hinzuzufügen, fand ich nichts Besonderes zur Cache-Kontrolle. Die einzige Ressource, die ich bekam, ist ResponseEntity: das Javadoc. Und der nützlichste Artikel für ETag ist http://www.baeldung.com/etags-for-rest-with-spring.Warum schlechte Unterstützung für http-Cache-Steuerelement in Spring MVC?

Das macht mich verwirrend ... Wenn die Cache-Steuerung wirklich großartig ist, warum wenig Unterstützung für Etag Generation und Cache-Steuer-Ressourcen gefunden? Oder ist das momentan nicht die beste Vorgehensweise?

Im Moment sieht meine Implementierung wie folgt aus:

@RestController 
public class Api { 

    @GetMapping("/with-cache") 
    public ResponseEntity cache() throws InterruptedException { 
     HttpHeaders httpHeaders = new HttpHeaders(); 
     httpHeaders.setCacheControl("max-age=3600"); 
     httpHeaders.setETag("\"3Rstthw\""); 
     Thread.sleep(1000); 
     return new ResponseEntity<>("Hello", httpHeaders, HttpStatus.OK); 
    } 
}

nicht sehr elegant aussieht. Hoffe jemand kann eine Antwort dafür geben.

Quelle

2017-10-23 aisensiy

Ist es wichtig "warum"? Beachten Sie, dass es sich um eine Q & A-Site und keine Diskussionsrunde handelt. –

Was denkst du, wäre "bessere" Unterstützung? --- Beachten Sie, dass Etags nicht "generiert" werden. Sie stellen die * Version * der betreffenden Ressource dar. Z.B. so formuliert es [Wikipedia] (https://en.wikipedia.org/wiki/HTTP_ETag): * Ein ETag ist eine undurchsichtige Kennung, die von einem Webserver einer ** spezifischen Version einer Ressource zugewiesen wird, die an einer URL * gefunden wird. *. Wenn sich die Ressourcendarstellung bei dieser URL ändert, wird ein neues und anderes ETag zugewiesen. * Da Spring nicht weiß, woher die Nutzdaten der Antwort stammen, wie kann Spring wissen, welche Version dieser Nutzlast es ist? – Andreas

Anmerkungen were considered for response headers aber entschieden dagegen, so müssen Sie es irgendwie manuell handhaben (nicht unbedingt wie in Ihrem Code).

Der Hauptgrund, sich dagegen zu entscheiden, ist die Art und Weise, in der Antworten mit möglichen Umleitungen usw. komplex sind, sodass Anmerkungen schlecht passen.

Zitat aus dem letzten Kommentar

Der spezifische Anwendungsfall brachte hier ist Cache-Control. Beachten Sie, dass wir in 4.1 ResponseEntity-Builder hinzugefügt haben und in 4.2 einen CacheControl-Builder hinzugefügt haben, der mit den ResponseEntity-Buildern funktioniert , was es sehr praktisch macht, dies zu tun, wenn er mit eTags und lastModified kombiniert wird (eine automatische Prüfung + 304). Wir haben auch speziell gegen einen @CacheControl-Header betrachtet und entschieden, da dies eine übergreifende Anforderung ist. Stattdessen kann der WebContentInterceptor verwendet werden, um den Cache Einstellungen pro URL-Muster zu konfigurieren und akzeptiert einen CacheControl Builder als gut.

Quelle

2017-10-23 07:30:14 Kayaman

Warum schlechte Unterstützung für http-Cache-Steuerelement in Spring MVC?

Antwort

Verwandte Themen