Been quiet on the Pedestal front for a bit - what I’m working on currently is turning the code that exposes classpath and file-system resources as request endpoints from special interceptors separate from routing into routing fragments that can be merged into your application’s main routes. There’s pluses and minuses to this new approach (I don’t think we’ll deprecate the old approach) but on the plus side, I should be able to adapt the fast resources to both file system and classpath. There’s also room for some caching that may make resource requests minutely faster. Pros: consistent, logged and traced with all other routes, code is better tested, easier to limit requests to specific host/port/scheme (like anything else that’s routed) Cons: have to watch out for conflicts with API routes; subject to all interceptors that routing is (so, maybe you don’t want resource URLs logged and traced, etc.)
Resources might be cached by the JVM anyway?
I like the pros. About the cons: if I "dont want the resource to be logged", i will tweak my "cloudflare proxy" and ask to cache this resource.
Looking more carefully at http/default-interceptors ... the resource and/or file interceptors occur immediately before the routing interceptor, so there's actually not much of a change there, which leads me towards deprecating the other options.
Caching: frequently accessed files will move to the OS’ page cache, where access can be very fast. What we’re really caching is the results of lookups, resolving the path to a File, resource URL, JarFile+JarEntry, etc., depending on the case.
I'm past principal development now, working on the documentation.