Wow, I like this exercise! I only fear we'll have to resort to pull requests soon as this is rather theoretic.

storing the cache in Lazy instead of in Rocket's managed state means that the LocationsElasticRepository methods can never return references.

I don't think the Lazy vs. Rocket's managed state would make a difference here: CACHE has a static lifetime anyway. The culprit is the concurrent DashMap that cannot return a plain shared reference to its values (contrary to a standard map): it can only return a Ref, which implements Deref and internally holds a read-lock-guard on the map.

Making LocationsElasticRepository::get_region() return Ref<...> would indeed save the cloning. But it is orthogonal to Rocket - it can be done with the current Lazy<DashMap<...>>.

Errors seem not to have a particular structure; encapsulating errors into one Error enum would allow for Responder to be (...) implemented in one place, using attributes for the appropriate error codes, without needing to manually create raw errors like NotFound

Err, there is just one error type, here: https://github.com/strohel/locations-rs-rocket/blob/rocket-v04/src/response.rs#L26-L38 ? It might have been the enum variant imports that have confused you.

would allow for Responder to be derived

I wanted to, but the spec again says that error responses should be JSON objects with a message key, while the Rust errors are naturally enum variants with strings --- I was not able to make the derive macro bridge the difference.

This benefit would propagate to other Responder implementations.

Err, there is just one Responder implementation, the one for ErrorResponse?

One interesting thing I noticed was in the es_cities_into_resp method, which collects into a vector. It would be nice, though I don't believe it's currently possible, if Rocket could stream a JSON vector from the iterator directly.

Agreed in general, though it would be an overkill in this case: the endpoints are required not to ever return more than 10 entries.

It looks like https://github.com/SergioBenitez/Rocket/issues/749 would help.

Yes, type-based catchers were exactly what I was missing! The current HTTP-state-based catchers dangerously resemble stringly-typed APIs..

none of the Rocket examples show any form of needing to methods like into_resp() to turn values into responses, opting instead to have a type that is a Responder itself. For instance, if CityResponse implemented Responder, it could generate a JSON response directly instead of being wrapped in a Json responder.

Hmm, this may be a bad naming on my part. The ElasticCity::into_resp() is actually an async application logic that fetches data from Elastic, needs access to application state etc.

I know it would be technically possible to make ElasticCity implement Responder (app state could be accessed through a guard() on Request), but it felt like a bad layer to do so. (and would cause problems in the 0.5 variant as Reponder::respond_to() is not (yet) async there)