Stéphane Épardaud
Stéphane Épardaud
> Not to mention that this all needs to work for async return types as well - presumably streaming types don't get this treatment at all Async for sure, and...
As for streaming, anything streamed can still be captured for caching, but we can definitely start with not supporting it.
We could also take a look at how other frameworks implement this, even if it's in NodeJS or RoR or whatever.
Note that this is also a REST client feature, as it turns out.
There's a RoR plugin to do this automatically, via an interceptor (most examples in most languages I've found use interceptors and/or annotations (Go, Python, JavaScript): https://github.com/julik/idempo/blob/main/lib/idempo.rb It has a list...
> It is? Other than add the special header, what else does the client need to do? Well, it depends on where/how are retries implemented. The article I read mentioned...
I think, the problem is that the user is writing a request filter and wants to access the exception, but the API for the response context only lets you access...
I'm not sure we should add access to the exception in the response filter. I feel like this is bypassing the separation of responsabilities in the API. Exception mappers are...
Oh, now I get it. You want to map exceptions to JSON but still forward the HTTP Status Code selection to other exception mappers. That's an interesting use-case. We did...
Well, I'm thinking that any mapper that calls back into the system will be excluded from the recursive call, until the last mapper (if they're all recursive) cannot map anything...