When multiple matches are found in lookupHandlerMethod, comparison by PatternsRequestCondition leads to strange results. [DATAREST-1495]

jvanheesch opened DATAREST-1495 and commented

Please see reference url for quick reproducer demonstrating strange behavior with a failing unit test.

GET /authors/search returns 400 BAD_REQUEST.
If in the project we replace all 3 instances of authors with author, then the test will magically pass.
This strange behavior is purely caused by the length difference between the strings "author" and "authors".

GET /authors/search results in 3 matches in AbstractHandlerMethodMapping.lookupHandlerMethod(String lookupPath, HttpServletRequest request)

matches = {ArrayList@15142}  size = 3
 0 = {AbstractHandlerMethodMapping$Match@15145} "{GET /authors/{id}, produces [application/hal+json]}"
 1 = {AbstractHandlerMethodMapping$Match@15146} "{GET /{repository}/search, produces [application/hal+json]}"
 2 = {AbstractHandlerMethodMapping$Match@15147} "{GET /{repository}/{id}, produces [application/hal+json]}"

with bestMatch

{GET /authors/{id}, produces [application/hal+json]}

This outcome is determined by PatternsRequestCondition, which in turn uses AntPatternComparator.
The AntPatternComparator's final decision is made based on length, where the length of templates is considered 1.
In this case
"/{repository\}/search" has length 1+1+7=9
"/authors/{id\} has length 9+1=10
When we replace authors with author, AntPatternComparator's comparison returns 0, and the final decision is made by ProducesRequestCondition in favor of

{GET /{repository}/search, produces [application/hal+json]}

I don't know how SDR should handle conflict resolution when multiple matches are found, however, I do believe warts like this should be avoided wherever possible

Reference URL: https://github.com/jvanheesch/spring-data-rest-search-resource