Unable to create resource at path '/user/{userId}/fans': A sibling ({bizId}) of this resource already has a variable path part -- only one is allowed

[helloworldtang]

"paths": {
"/user/{bizId}/complaint": {
.....
,
"/user/{userId}/fans": {
"get": {

Import the format of the data above, will cause the wrong below：

Your API was not imported due to errors in the Swagger file.
Unable to create resource at path '/user/{userId}/fans': A sibling ({bizId}) of this resource already has a variable path part -- only one is allowed
Additionally, these warnings were found:
No responses specified for 'POST /user/{bizId}/complaint'

[lorenzoaws]

This is by design, precisely because of the message in the error. Can you do this instead?

"paths": {
"/user/{bizId}/complaint": {
.....
,
"/user/{bizId}/fans": {
"get": {

[helloworldtang]

Thanks for your time and reply.
@lorenzoaws yes,i change the rest api.
However, this restriction conditions make people more confused

[danibrear]

This has caused us a big headache recently and only by finding this issue was I able to resolve it. We have a micro service architecture where a user has both an ID and a UUID.

/users/{userUUId}/ -> userUUId is global to the application
/users/{userId}/memberships/ -> userId is relative to the service

We were naming our variables with either userId for same service or userUUId for extended services and this "by design" feature caused our deploys to break for a week. The work around for us is to use the same variable name and then in the methods that are being called, make sure to add many comments aliasing this variable to what it actually is.