Getting same responses for different paths if paths are like /tests and /tests/results about imposter HOT 7 CLOSED

Hey @outofcoffee thanks for fixing this.

from imposter.

Hi @Satish1994 - thanks for taking the time to raise this. The issue you referenced was closed after the issue author did not provide a Swagger/OpenAPI file and config file that reproduced the issue. The ticket was open for several months but unfortunately no details were provided :(

Are you able to provide this information to help diagnose the problem?

from imposter.

Here is my config file

plugin: openapi
specFile: openapi.yaml

from imposter.

Here is my openapi.yaml spec file

https://gist.github.com/satish1994/8c9d5ac106dbe9ea310017bbe842ec1b
Consider two request /transfers with GET method and /transfers/accounts with GET method, if I try GET /transfers/accounts, I receive the responses of /transfers instead of /transfers/accounts, both have different example responses

from imposter.

Hi @Satish1994, from what I can see, the request path /transfers/accounts is matching the OpenAPI operation for /transfers/:id when the request is received. It seems that account is being interpreted as the id path parameter. This is obviously not what you expected given there is an explicit operation for /transfers/accounts.

As far as the identical response is concerned, in your OpenAPI spec, the examples for /transfers and /transfers/:id are the same - I suspect, based on the model reference in the listTransfers operation that you intended the example for that to be an array (as per StandardResponseCollectionTransferResponseVO rather than StandardResponseTransferResponseVO).

In any case, the matching to operation by exact path is ambiguous, so we should consider that a bug.

The path matching is performed by Vert.x Web rather than any custom logic in Imposter. The issue is described in this Stack Overflow post: https://stackoverflow.com/questions/49829056/vertx-web-route-distinction-between-the-path-uri-and-path-param

It seems reasonable for Imposter to prefer routes with exact matches over those with path placeholders, so I will make this change in the next release (v2.13.0).

from imposter.

Hi @Satish1994 v2.13.0 is now released - does this resolve your issue?

from imposter.

Closing as fixed. Please feel free to raise a new issue if there is still a problem.

from imposter.