title: Conflicting method/path combination for action - Swagger unable to distinguish alternate version from Route
body: <p>I have the following controller setup in my solution:</p>
  <pre class="lang-cs prettyprint-override"><code>[Route(&quot;api/v{VersionId}/[controller]&quot;)]
  [ApiController]
  [Produces(&quot;application/json&quot;)]
  [Consumes(&quot;application/json&quot;)]
  public class MyBaseController : ControllerBase
  {
  }
  
  [ApiVersion(&quot;1.0&quot;)]
  [ApiVersion(&quot;1.1&quot;)]
  public class AuthenticationController : MyBaseController
  {
      private readonly ILoginService _loginService;
  
      public AuthenticationController(ILoginService loginService)
      {
          _loginService = loginService;
      }
  
      [ProducesResponseType(StatusCodes.Status200OK)]
      [ProducesResponseType(StatusCodes.Status403Forbidden)]
      [ProducesResponseType(StatusCodes.Status404NotFound)]
      [ProducesResponseType(StatusCodes.Status500InternalServerError)]
      [ProducesResponseType(StatusCodes.Status400BadRequest)]
      [HttpPost(&quot;login&quot;)]
      public ActionResult&lt;v1.JwtTokenResponse&gt; Login([FromBody] v1.LoginRequest loginRequest)
      {
          var loginResult = _loginService.Login(loginRequest.Email, loginRequest.Password);
          if (loginResult.StatusCode != HttpStatusCode.OK)
          {
              return StatusCode((int)loginResult.StatusCode);
          }
  
          var tokenResponse = new v1.JwtTokenResponse() { Token = loginResult.Token };
  
          return Ok(tokenResponse);
      }
  }  
  </code></pre>
  <p>Between the two versions of my API, nothing has changed for this method and so logically in my documentation I want to display that the method is still supported in the new version. Let's argue that we have a second controller of customer that has had some changed logic and hence is the reason why we have the new version 1.1 as semantic versioning dictates something new has been added but in a backwards compatible manner.</p>
  <p>When running this code, naturally everything builds fine. The code is valid and .net core allows this sort of implementation however, when it comes to the swagger gen I am hitting issues with it producing the following error:</p>
  <pre><code>NotSupportedException: Conflicting method/path combination &quot;POST api/v{VersionId}/Authentication/login&quot; for actions - Template.Api.Endpoints.Controllers.AuthenticationController.Login (Template.Api.Endpoints),Template.Api.Endpoints.Controllers.AuthenticationController.Login (Template.Api.Endpoints). Actions require a unique method/path combination for Swagger/OpenAPI 3.0. Use ConflictingActionsResolver as a workaround
  </code></pre>
  <p>As you can see above, the path is different because the version parameter passed into the route makes it that way. Furthermore, it does not make sense to create a brand new method purely to represent that the code is available through documentation so, my question is why is swagger ignoring the version differences in the path and suggesting the user of the ConflictingActionsResolver?</p>
  <p>Furthermore, after digging into this further and seeing that a lot of other people were having the same issue (with header versioning being a particular bugbear of the community and Swaggers hard-line approach being in conflict with this) the general approach seems to be to using the conflicting actions resolver to only take the first description it comes across which would only expose version 1.0 in the api documentation and leave out the 1.1 version giving the impression in Swagger that there is no 1.1 version of the endpoint available.</p>
  <pre class="lang-cs prettyprint-override"><code>Swagger UI Config
  
  app.UseSwaggerUI(setup =&gt;
  {
     setup.RoutePrefix = string.Empty;
  
     foreach (var description in apiVersions.ApiVersionDescriptions)
     {
        setup.SwaggerEndpoint($&quot;/swagger/OpenAPISpecification{description.GroupName}/swagger.json&quot;,
                              description.GroupName.ToUpperInvariant());
     }
  });
  
  </code></pre>
  <p>How can we get around this and correctly display available endpoints in Swagger without having to create new methods that effectively result in a duplication of code just to satisfy what seems like an oversight in the Swagger spec? Any help would be greatly appreciated.</p>
  <p>N.B. Many may suggest appending action on to the end of the route however we wish to avoid this as it would mean our endpoints are not restful where we want to strive for something like customers/1 with the GET, POST, PUT attributes deriving the CRUD operations without having to append something like customers/add_customer_1 or customers/add_customer_2 reflecting the method name in the URL.</p>