Replies: 1 comment
-
An other pattern where something like See API versioning: URL vs Header vs Media Type versioning This way you could do something like:
Right now implementing header based versioning is quite difficult to achieve, exactly because of this "routing" difficulty. And this is why people prefers implementing path-based (or URL based) versioning. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Most of the webhook emitter applications are sending different webhook events (represented by different java classes) to the same url. Often there is a header for example
X-Gitlab-Event
indicating which type of event is sent.List of all the events you can get from GitLab:
https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html
I am curious what you recommend for this kind of implementation with Java.
As far as I know, no matter what you use Quarkus REST, Quarkus Reactive Routes or the Spring Web annotations in Quarkus there is no way to dispatch a request to a java method by checking an header value.
You can get the value of a given header
@RestHeader
or@HeaderParam
but then you still need to write the switch and somehow you need to de-serialise manually.Something like:
But you need to write the
convert(..)
method manually (that is calling a deserializer like Jackson).The situation can be a little bit improved if all your models share a common interface:
But you still need the switch case and the cast:
Ideally I would like to do something like:
Beta Was this translation helpful? Give feedback.
All reactions