Documentation Clarification on RestClient and Custom properties contains errors?

[tmulle]

@lwitkowski

I'm a little unclear on how to use the custom properties extension according to your documentation.

In my tester https://github.com/tmulle/quarkus-resteasy-problem-test

How would I pass a custom HttpProblem from the server side up to my RestClient running in another process?

Using straight HttpProblem with my example it now works and no longer causes the truncation! Great work!

My questions are:

1. Where does the custom MyHttpProblem code go? in the server (throwing side)? or in the client (Catching side) or both?

2. Your example of the custom MyHttpProblem doesn't compile because it complains about a missing explicit constructor.

Thanks

[pazkooda]

Ad. 1) MyHttpProblem is just a way to provide OpenAPI a structured class with predictable naming of extension fields as of RFC.
You may use it as you base class in code instead of directly using HttpProblem.

If you will use HttpProblem-only response will still contain extension fields, just those will not be exposed to OpenAPI spec.

Ad 2) In README.md minimial examples are provided that express purpose of particular feature. If we where to provide complete (compilable) classes it will become unreadable. Thus explicit constructor "should be there by implication" (same with imports 😉 )

[lwitkowski]

Hey @tmulle, @pazkooda answered both questions, so I'll just add my 2 cents to your question nr 1:

1. Where does the custom MyHttpProblem code go? in the server (throwing side)? or in the client (Catching side) or both?

It must exist in the server (the throwing side) for 2 reasons (as @pazkooda mentioned):

• to generate proper openapi yaml documenting your api
• (optional) to throw customized Problems programmatically from your app's code

Regarding catching side, it all depends on use case:

• if your catching side is just a gateway, or an application that just rethrows Problems further: registering ThrowingHttpProblemClientExceptionMapper may be good enough - it throws raw HttpProblems from this lib, but with all custom fields preserved - nothing gets lost.
• if your catching side wants to receive strongly typed MyHttpProblem to read its contents - you can use MyHttpProblem pojo generated from open api (with custom version of ThrowingHttpProblemClientExceptionMapper I guess).
• if your catching side wants to receive strongly typed MyHttpProblem and rethrow it (POJO generated from open api is not Throwable) then you need to duplicate MyHttpProblem class from the throwing side and extend ThrowingHttpProblemClientExceptionMapper to throw MyHttpProblem instead of HttpProblem (first deserialize to generic HttpProblem, then construct your class instance if you don't want to implement custom jackson/jsonb deserializer) - this could be a small 2-classes library (or bigger one, while java client for your rest api with everything preconfigured) shared between your microservices.

Right now I can't think of how we could improve that in a generic way in this extension, but I'm open for suggestions of course.
And a summary of this thread will probably end up in Wiki tab of this repo.