Sandbox suggestion: Java standard for problem details [rfc-7807]

[Rüdiger zu Dohna]

Hi,

I’d like to contribute a standard for better generation and handling of http message bodies for application error conditions. I’ve just blogged about it: https://blog.codecentric.de/en/2020/01/rfc-7807-problem-details-with-spring-boot-and-jax-rs/

tl;dr: exceptions get mapped to rfc-7807 compliant application/problem+json http bodies on the server side and/or back to exceptions on the client side. You can rely on useful defaults for the fields or annotate your exceptions when you have specific requirements.

I have a potential implementation here that runs on Payara and Open Liberty, and mostly on Widlfly... and on Spring Boot.

So most of the code is there, and I'm working on the spec text.

I already opened a PR: https://github.com/eclipse/microprofile-sandbox/pull/78.

Ken suggested:

Have you suggested this to Jakarta RESTful Web Services spec? From a quick look through it appears more appropriate as additions there.

I thought about this first, actually; and I'm still open for the suggestion. The downside would be that it would make the implementation in Spring Boot more difficult and maybe even restrict it to projects fully using JAX-RS.

What do you say?

Rüdiger

[Emily Jiang]

Hi Rüdiger,

Thanks for sharing this with us! I see this is a useful tool for exception mapping. I think it has merit on both MP Rest client and JAX-RS. I like the idea. With what you have got, it is much easier to display a meaningful human readable messages. I am wondering whether you can also directly map a return code to a type of exception specified?

For the next step, you can open an issue on MP Rest Client to investigate how to incorporate into that spec. In addition to that, you may also go to Jakarta Restful Webservice community to talk about your idea (as per Ken's comments).

Thanks

Emily

[Sergey Beryozkin]

Hi

Ideally it would be optional (recommended vs required) for a given implementation to do because enforcing a format for a given HTTP error response is always creating some 'tension' and sometimes can also leak too much information for a response like 401/403.

Thanks, Sergey

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/85298678-1cfa-4713-8e18-0f4a9e223a04%40googlegroups.com.

[Rüdiger zu Dohna]

Hi Emily,

On Thursday, January 23, 2020 at 11:38:59 AM UTC+1, Emily Jiang wrote:

I am wondering whether you can also directly map a return code to a type of exception specified?

You mean that a response without a problem detail response entity would be mapped to a custom exception? Would be possible, as long as there is only a single exception for that status code. Could make the code brittle though, as adding a new type could fail the existing client code.

For the next step, you can open an issue on MP Rest Client to investigate how to incorporate into that spec.

I will do that. Maybe it's possible to extend the MP Rest Client APIs so that a ResponseExceptionMapper can access the API class to search for the exceptions. The heuristic I've used in my implementation is not clean.

In addition to that, you may also go to Jakarta Restful Webservice community to talk about your idea (as per Ken's comments). 

That would mean to move it over there entirely. I still like the idea of having a separate standard that could easily be implemented by Spring Boot as well. But I already have the same issue with the Status enum.

Thanks for the feedback!

Rüdiger

[Rüdiger zu Dohna]

Hi Siarhei,

On Thursday, January 23, 2020 at 12:20:16 PM UTC+1, Siarhei Biarozkin wrote:

Ideally it would be optional (recommended vs required) for a given implementation to do because enforcing a format for a given HTTP error response is always creating some 'tension' and sometimes can also leak too much information for a response like 401/403.

The idea is that the application developer has to opt-in. Behavior should not change when switching to another implementation. Now that I'm thinking about it, my proposal to use the exception message as the fallback detail field may actually be a security concern.

Thanks for your input!

Rüdiger

[Sergey Beryozkin]

Hi

You can call me Sergey too :-)

It can be useful, it is a good idea in a good number of cases and I would support Emily on it for sure, my only suggestion here is not immediately enforce it and review on per status basis, etc...

Cheers, Sergey

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0bbfb1c9-8076-4861-8176-6910f134a223%40googlegroups.com.

[Emily Jiang]

My response inline.

On Thursday, January 23, 2020 at 12:26:29 PM UTC, Rüdiger zu Dohna wrote:

Hi Emily,

On Thursday, January 23, 2020 at 11:38:59 AM UTC+1, Emily Jiang wrote:

I am wondering whether you can also directly map a return code to a type of exception specified?

You mean that a response without a problem detail response entity would be mapped to a custom exception? Would be possible, as long as there is only a single exception for that status code. Could make the code brittle though, as adding a new type could fail the existing client code.

I meant instead of creating a ExceptionMapper for mapping a return code to a particular exception. Will you be able to add a new annotation to directly map the return code to an Excpetion without the need to create ExceptionMapper boilerplate?

For the next step, you can open an issue on MP Rest Client to investigate how to incorporate into that spec.

I will do that. Maybe it's possible to extend the MP Rest Client APIs so that a ResponseExceptionMapper can access the API class to search for the exceptions. The heuristic I've used in my implementation is not clean.

Sounds good.

[Rüdiger zu Dohna]

On Thursday, January 23, 2020 at 4:47:28 PM UTC+1, Emily Jiang wrote:

On Thursday, January 23, 2020 at 12:26:29 PM UTC, Rüdiger zu Dohna wrote:

On Thursday, January 23, 2020 at 11:38:59 AM UTC+1, Emily Jiang wrote:

I am wondering whether you can also directly map a return code to a type of exception specified?

You mean that a response without a problem detail response entity would be mapped to a custom exception? Would be possible, as long as there is only a single exception for that status code. Could make the code brittle though, as adding a new type could fail the existing client code.

I meant instead of creating a ExceptionMapper for mapping a return code to a particular exception. Will you be able to add a new annotation to directly map the return code to an Excpetion without the need to create ExceptionMapper boilerplate?

On the client as well as on the server side, the application developer only writes and throws or catches exceptions; you only annotate them when the defaults are not sufficient for you. All the mapping is done by the implementation. My POC implementation works really good on the server side and mostly good on the client side... there are just some glitches regarding the discovery of the exceptions to potentially map to... you may have to register them manually. And you may have to unpack the ResponseProcessingException. Maybe I could write a CDI extension to scan for all exceptions.