Regardless whether versioning can be avoided by doing backwards compatible changes (which might not always possible when you are bound by some corporate guidelines or your API clients are implemented in a buggy way and would break even if they should not) the abstracted requirement is an interesting one:
How can I do a custom request mapping that does arbitrary evaluations of header values from the request without doing the evaluation in the method body?
As described in this SO answer you actually can have the same @RequestMapping
and use a different annotation to differentiate during the actual routing that happens during runtime. To do so, you will have to:
- Create a new annotation
VersionRange
. - Implement a
RequestCondition<VersionRange>
. Since you will have something like a best-match algorithm you will have to check whether methods annotated with otherVersionRange
values provide a better match for the current request. - Implement a
VersionRangeRequestMappingHandlerMapping
based on the annotation and request condition (as described in the post How to implement @RequestMapping custom properties
). - Configure spring to evaluate your
VersionRangeRequestMappingHandlerMapping
before using the defaultRequestMappingHandlerMapping
(e.g. by setting its order to 0).
This wouldn’t require any hacky replacements of Spring components but uses the Spring configuration and extension mechanisms so it should work even if you update your Spring version (as long as the new version supports these mechanisms).