GithubHelp home page GithubHelp logo

sebazzz / sdammann.webapi.versioning Goto Github PK

View Code? Open in Web Editor NEW
174.0 24.0 44.0 8.02 MB

Versioning support for ASP.NET Web Api

License: Apache License 2.0

Shell 0.02% C# 80.71% CSS 0.35% ASP 0.02% HTML 0.68% JavaScript 0.07% Pascal 16.73% Puppet 1.42% PowerShell 0.01%

sdammann.webapi.versioning's Introduction

SDammann.WebApi.Versioning

Easy, well-tested, and extendable ASP.NET Web API versioning.

There is also a Nuget package available.

Using the library

Setting up

Register the DefaultControllerIdentificationDetector and DefaultRequestControllerIdentificationDetector class with your dependency container.

Next, choose a versioning scheme and register it with the library. For example, to use versioning by API route (this will use urls like /api/v1.2/product/) include the following in your Web API configuration delegate:

ApiVersioning.Configure(config)
             .ConfigureRequestVersionDetector<DefaultRouteKeyVersionDetector>();

The code assumes the config variable is of type HttpConfiguration. Make sure to register this class with your dependency container.

Choosing an API versioning scheme

Currently the library supports two API versioning schemes.

API versions by URL / routing.

This will allow the API version to be chosen by your URL routing scheme. Example:

config.Routes.MapHttpRoute(
	name: "DefaultApi",
	routeTemplate: "api/v{version}/{controller}/{id}",
	defaults: new { id = RouteParameter.Optional }
);

ApiVersioning.Configure(config)
             .ConfigureRequestVersionDetector<DefaultRouteKeyVersionDetector>();

API versions by HTTP header

A scheme preferred by many REST purists. This allows the API version to be chosen by using the MIME type in the Accept header of the request. In order to achieve this, inherit from AcceptHeaderRequestVersionDetector and implement the GetVersionFromSingleHeader method.

Next, register your implementation in the Web API configuration delegate:

ApiVersioning.Configure(config)
             .ConfigureRequestVersionDetector<YourCustomRoutingDetector>();

Don't forget to set-up your custom MIME-type in content negotiation so ASP.NET Web API will output the correct response format.

Concepts

The library distinguishes several responsibilities in API versioning:

  • Controller naming / versioning
  • External request naming / versioning
  • The definition of a version itself

Controller name and version detection are implemented using the IControllerNameDetector and IControllerVersionDetector interfaces. The default DefaultControllerNameDetector implementation uses the ASP.NET Web API conventions, like requiring your controller class name to end with Controller. The default DefaultControllerVersionDetector expects you to put your controllers in 'versioned' namespaces. For instance, controllers in namespace MyApi.Version1_1 will point to version 1.1 of the API. There is also an implementation available that allows you to use attributes instead (DefaultAttributeControllerVersionDetector).

Request controller naming and versioning is implemented using the IRequestControllerNameDetector and IRequestVersionDetector interfaces. The default DefaultRequestControllerNameDetector implementation uses the ASP.NET Web API conventions. There is no default IRequestVersionDetector configured. The library forces you to choose an API versioning scheme.

An API version itself is abstracted away as an ApiVersion. This is an abstract class that allows the concept of versioning itself to be customizable. For example, the SemVerApiVersion uses a one to four numbers to be used for API versions. One could easily extend this to support letters, for example as designation for 'beta' and 'alpha' by inheriting from SemVerApiVersion and then implement IControllerVersionDetector and IRequestVersionDetector or extend the existing implementations.

Advanced concepts

Custom exception handling

By default the library will properly handle exceptions that occur during controller selection itself. In some cases you may want to override or modify the error messages returned to the client by this library. You may do this in two ways:

  1. Implementing a global exception handler and handle any BaseApiException derived exception yourself, as per ASP.NET Web API documentation. Note that the library registers it's own exception handler, but you may wish to use your own. In that case you can always delegate any exception handling to IVersioningExceptionHandler.

  2. Implement a custom IVersioningExceptionHandler. This exception handler is called by the library when a API versioning error occurs. You can implement your own custom response here. You can also inherit or delegate to DefaultVersioningExceptionHandler if you can't or won't handle an exception in certain cases.

Extending the identification of a controller

By default, a Web API controller is identified by its version and name (in the form of a ControllerIdentification instance). It is possible to extend or modify this behavior. This is done by inheriting from the ControllerIdentification class and implementing custom versions of the IControllerIdentificationDetector and IRequestControllerIdentificationDetector interfaces or extending the default implementations.

Note this is usually not necessary, but if you'd like to go beyond names and versions you can use this approach.

Contact

Any questions or remarks? Drop me a twitter message (@sebazzz91) or put an issue in the issue tracker.

Older version

The legacy older version (2.x) is available at the 2.x branch.

License

Apache 2.0 license. License details are available in the LICENSE file.

sdammann.webapi.versioning's People

Contributors

davidsavagejr avatar giorgistoynev avatar goalie7960 avatar joachiml avatar patrickrobbins avatar razorsmith avatar sebazzz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sdammann.webapi.versioning's Issues

Incorrect NuGet dependencies?

Your nuspec claims this package depends on the following packages:

Microsoft.AspNet.WebApi
Microsoft.Web.Infrastructure
Microsoft.Net.Http

I'm not an expert on NuGet dependencies, but I suspect this might be incorrect. It seems like Microsoft.AspNet.WebApi would be required, because that's the main Web API package itself, but the other two seem unrelated, and end up filling the user's project with all that Microsoft.Bcl mess.

I grabbed the code, built it locally, and just imported the DLL, without the package, and my project worked perfectly without Microsoft.Bcl, or Microsoft.Net.Http, or anything else.

Maybe we can remove these and save some NuGet bloat for the users of this package?

Add support for the version accept header property

An alternative approach is to use the accept version header property i.e.

Accept: applicaton/foo;version=1.0

this reduces the need to mint new media types per version yet still gives the client the ability to choose.

DLL Depends on System.Web.Http 5.1.0.0

Hello,

I'm using SDammann.WebApi.Versioning 2.5.0.0 and it still requires System.Web.Http 5.1.0.0. I'm currently using System.Web.Http 5.2.2.0. Is there a reason it requires the older version?

Thanks in advance.

MvcApplication3.Areas.HelpPage.XmlDocumentationProvider' does not implement interface member 'System.Web.Http.Description.IDocumentationProvider.GetResponseDocumentation

Hi,
I'm experimenting on a new WebAPI Solution and it builds fine initially. When I install the Install-Package SDammann.WebApi.Versioning package I get the following error on building:

Error 2 'MvcApplication3.Areas.HelpPage.XmlDocumentationProvider' does not implement interface member 'System.Web.Http.Description.IDocumentationProvider.GetResponseDocumentation(System.Web.Http.Controllers.HttpActionDescriptor)' C:\dev\Scratch\WebAPI\ControllerVersioning\UsingSDammannNuget\MvcApplication3\MvcApplication3\Areas\HelpPage\XmlDocumentationProvider.cs 14 18 MvcApplication3

I even get this with the "Install-Package SDammann.WebApi.Versioning -Pre" package

Strange behaviour for AcceptHeaderVersionedControllerSelector

The relationship between AcceptHeaderVersionedControllerSelector and ASP.NET's logic for actually serializing the http response body is a bit strange. You can cause some strange situations with a header like Accept: application/json; q=0.8; version=1, application/xml; q=0.9; version=1. If I leave the default AcceptMediaType = "application/json", then AcceptHeaderVersionedControllerSelector is going to use that media type to pick the version, while ASP.NET will still return an XML body.

Things get even weirder if you change the XML's accept version: Accept: application/json; q=0.8; version=1, application/xml; q=0.9; version=2. AcceptHeaderVersionedControllerSelector still uses the JSON to pick version 1, then actually sends back version 1 XML. This could really confuse the client.

I've been scratching my head on this for a bit, thinking of changing AcceptMediaType to an IEnumerable<string>, and ordering the IEnumerable<MediaTypeWithQualityHeaderValue> acceptHeader by q value before passing in to GetVersionFromHeader(), but there's still a diconnect between AcceptHeaderVersionedControllerSelector and what format ASP.NET ultimately returns in the body.

Any ideas?

Ability to change version header name in VersionHeaderVersionedControllerSelector

I have a requirement to use a naming convention specific to my organization for specifying version header. Currently this appears as public const string ApiVersionHeaderName = "X-Api-Version"; in VersionHeaderVersionedControllerSelector. Can this be overridden with a config key in configuration file or in some other ways?

Routing issue

        config.Routes.MapHttpRoute(
            name: "Route1",
            routeTemplate: "api/v{version}/Participant/{action}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );

        config.Routes.MapHttpRoute(
            name: "Route2",
            routeTemplate: "api/v{version}/{controller}/{action}/{id}",
            defaults: new { id = RouteParameter.Optional }               
        );

If i add two routes, exception is thrown from SDamman dll (object null reference error)

An exception of type 'System.NullReferenceException' occurred in SDammann.WebApi.Versioning.dll but was not handled in user code

Additional information: Object reference not set to an instance of an object.

at SDammann.WebApi.Versioning.VersionedControllerSelector.GetControllerNameFromRequest(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedControllerSelector.cs:line 187
at SDammann.WebApi.Versioning.RouteVersionedControllerSelector.GetControllerIdentificationFromRequest(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\RouteVersionedControllerSelector.cs:line 34
at SDammann.WebApi.Versioning.VersionedControllerSelector.SelectController(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedControllerSelector.cs:line 112
at System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsyncInternal(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

get_Services not found

  1. Nuget package
  2. Update Global.asax with RouteVersionedControllerSelector
  3. Changed route template to api-{version}/{controller}/{id}
  4. Updated namespace to ...API.Controllers.Version1 and ...Version2
  5. Navigating to generic ValuesController via /api-1/values

Result: YSOD - Method not found: 'System.Web.Http.Services.DefaultServices System.Web.Http.HttpConfiguration.get_Services()'.

Recently updated from VS2012 RC to latest version, I've seen some people suggesting leftover dlls in GAC.

Any thoughts?

Accessing invalid version containing letters throws exception

This is my route configuration:

config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{version}/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);

I don't want to use "api/v1/". I like "api/1/" better.
I was testing it and if I try to access "api/x/" an exception is thrown:

An error has occurred.Specified cast is not valid.System.InvalidCastException at SDammann.WebApi.Versioning.VersionedControllerSelector.GetVersionRouteDefaults(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedControllerSelector.cs:line 155
at SDammann.WebApi.Versioning.VersionedControllerSelector.SelectController(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedControllerSelector.cs:line 118
at System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__0.MoveNext()

Do you think you can fix it? IMHO returning an error saying the version wasn't find would be better.

ArgumentException with VersionedApiExplorer

I am using the RouteVersionedControllerSelector for MVC5 WebAPI.

In my WebApiConfig.cs file, I have the following lines:

config.Services.Replace(typeof(IApiExplorer), new SDammann.WebApi.Versioning.VersionedApiExplorer(config));
config.Services.Replace(typeof(IHttpControllerSelector), new SDammann.WebApi.Versioning.RouteVersionedControllerSelector(config));

Now, inside my controller class, I have these two functions declared:
namespace v1
{
[HttpGet]
[ResponseType(typeof(Collection))]
public Collection GetPendingOpens( [FromUri(Name="count")] int aCount = 25)
{
/*
*/
}
public Collection GetTemplateData
(
[FromUri(Name="tname")]
string aTemplateName,

            [FromUri(Name="tplatform")]
            TemplatePlatform? aTemplatePlatform = null,

            [FromUri(Name="tlanguage")]
            // [StringLength(2)]
            string aTemplateLanguage = null,

            [FromUri(Name="tversion")]                
            int? aVersion = null
    )
    {
        /*
        */
    }
}

When I attempt to load the Api help page (default in WebAPI projects), I am greeted with the attached image.
error

Am I doing something wrong here?

Integrating Versioning in an already in production API

Hi,
Currently there is no way to implement versioning in an already implemented and in production API. What im doing to implement it is

config.Routes.MapHttpRoute(
            name: "DefaultVersionedApi", 
            routeTemplate: "api/v{version}/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional });

config.Routes.MapHttpRoute(
            name: "DefaultApi", 
            routeTemplate: "api/{controller}/{id}", 
            defaults: new { id = RouteParameter.Optional });

Is .net 4.5 support?

I recently upgraded a project to .net 4.5. Everything is working fine except I get the build error below:

Error 104 The type or namespace name 'SDammann' could not be found (are you missing a using directive or an assembly reference?) C:\Datahug\Branches\NextRelease\Datahug.Api\Contollers\HomeController.cs 4 7 Datahug.Api

When I look at the build output it looks like the SDammann.WebApi.Versioning reference is not included in the csc command. I am guess this is because it was built for .net4?

Exception handling

I'd like to return different error messages to the user to attempt to explain the problems better. For example, rather than say that an API doesn't exist, I'd like to tell them if:

  1. They've omitted the version from the Accept header completely. I'd rather report this in a nice way than have a default version number.
  2. They've supplied an invalid version in the Accept header. This could just end up being the same as above.
  3. They've asked for a version number that doesn't exist (on any route). I'm not sure that this would be possible or not but it feels nicer than just saying that the API wasn't found when in fact that version number is not ever used.

I also found that I get The API 'SDammann.WebApi.Versioning.ControllerIdentification' doesn't exist returned when I omit the version header. Not sure why it's referring to a namespace that isn't mine but it's definitely not clear to users what's going on.

The problem is that since the code throws HttpResponseExceptions, I'm unable to handle them in a global error handler.

What do you think about either changing the type of exception thrown so it can be caught in the global error handler and handled appropriately, or even providing an error handling class that can be derived and injected into the configuration?

At the moment, the best I've come up with is deriving from VersionedApiControllerSelector and wrapping OnSelectController in a try/catch block so I can create a different response and throw another HttpResponseException. It would be nice to have a cleaner way of doing this.

(Using v3.0.0-beta1.)

Subversion Support

Hi,
Is it possible to support subversions?

Example:
/api/v1.2/values => namespace API.Controllers.Version1_2
/api/v1.2.1/values => namespace API.Controllers.Version1_2_1

Can't build because referenced nuget packages are not found

Both packages.config files reference 4.0.20726.0 of several Microsoft nugets. When building, nuget.exe exits with an error code trying to download these, because they presumably don't exist. Are these beta builds or something?

Changing the version to 4.0.20710.0, the current latest version available, fixes the problem.

Inherting from VersionedApiControllerSelector

I'm trying to create a custom versioning scheme that will allow a controller to "fall through" to a previous version of a controller if one is not defined for a particular version. This will allow me to only make classes in the new namespace when there are actual changes to that class. anything that stays the same will continue to work from the same code.

I would like to inherit from VersionedApiControllerSelector and create my own implementation of this class. This has some issues as this is the entry point into a lot of the code and many of the classes in the library are marked as internal or private.

I would consider changing the private variables in this class to protected. also the InitializeControllerInfoCache to a protected virtual method.

I could create a pull request with some changes that would make this easier to extend (from my perspective at least)

Ambiguous routes reported incorrectly

I have the following controller in my project:

namespace MyProject.Api.Version1
{
    [RoutePrefix("api/something")]
    public class SomethingController : ApiController
    {
        [Route("")]
        [HttpGet]
        public IHttpActionResult GetSomething()
        {
            return Ok();
        }

        [Route("else")]
        [HttpGet]
        public IHttpActionResult GetSomethingElse()
        {
            return Ok();
        }
    }
}

When I issue a GET /api/something or GET /api/something/else, I get an InvalidOperationException (details below). The exception message is:

Multiple actions were found that match the request: 
    Something on type MyProject.Api.Version1.SomethingController
    SomethingElse on type MyProject.Api.Version1.SomethingController

Despite the issue with the routes not being detected properly, I would've thought that if there was an error with multiple routes being detected, that it would throw an AmbigiousApiReqestException (using 3.0.0-beta3). Also note that Ambiguous is incorrectly spelt in that exception name.

I've also tried moving the GetSomethingElse() method into a separate SomethingElseController but that doesn't make a difference.

System.InvalidOperationException was unhandled by user code
  HResult=-2146233079
  Message=Multiple actions were found that match the request: 
Something on type MyProject.Api.Version1.SomethingController
SomethingElse on type MyProject.Api.Version1.SomethingController
  Source=MyProject
  StackTrace:
       at MyProject.Api.GlobalExceptionHandler.Handle(ExceptionHandlerContext context) in [...]\MyProject\Api\GlobalExceptionHandler.cs:line 19
       at System.Web.Http.ExceptionHandling.ExceptionHandler.HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
       at System.Web.Http.ExceptionHandling.ExceptionHandler.System.Web.Http.ExceptionHandling.IExceptionHandler.HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
       at System.Web.Http.ExceptionHandling.LastChanceExceptionHandler.HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
       at System.Web.Http.ExceptionHandling.ExceptionHandlerExtensions.<HandleAsyncCore>d__0.MoveNext()
  InnerException: 

If I look at the actual exception inside the global exception handler's ExceptionHandlerContext.Exception, the stack trace starts with:

at System.Web.Http.Controllers.ApiControllerActionSelector.ActionSelectorCacheItem.SelectAction(HttpControllerContext controllerContext)
at System.Web.Http.Controllers.ApiControllerActionSelector.SelectAction(HttpControllerContext controllerContext)
at System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken)
[...]

Configurable error messages

The error messages generated by the VersionedControllerSelector class could be configurable.
I think the message "The API 'Version2_2.values' doesn't exist" exposes to much information. if we where able to supress this message by just showing the common Not Found or configure our messages by setting those in the web.config would be nice.

ArgumentNullException when version header missing

I updated to 3.0.0-beta3 to incorporate the new exception handling changes but I'm not getting an ArgumentNullException when the version header isn't supplied. My understanding was that I should expect an ApiVersionNotDeterminedException instead but it looks to me like it's not getting to the line that checks for that.

My API uses the Accept header for versioning so I have a class derived from AcceptHeaderRequestVersionDetector. This used to work fine in beta1 but upon upgrading it has stopped working. Everything appears to work fine when the version is supplied in the Accept header.

Here's the exception details and stack trace:

System.ArgumentNullException was unhandled by user code
  HResult=-2147467261
  Message=Value cannot be null.
Parameter name: version
  Source=SDammann.WebApi.Versioning
  ParamName=version
  StackTrace:
       at SDammann.WebApi.Versioning.ControllerIdentification..ctor(String name, ApiVersion version) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\ControllerIdentification.cs:line 42
       at SDammann.WebApi.Versioning.Request.DefaultRequestControllerIdentificationDetector.GetIdentification(HttpRequestMessage requestMessage) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\Request\DefaultRequestControllerIdentificationDetector.cs:line 43
       at SDammann.WebApi.Versioning.VersionedApiControllerSelector.GetControllerIdentificationFromRequest(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedApiControllerSelector.cs:line 105
       at SDammann.WebApi.Versioning.VersionedApiControllerSelector.OnSelectController(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedApiControllerSelector.cs:line 70
       at SDammann.WebApi.Versioning.VersionedApiControllerSelector.SelectController(HttpRequestMessage request) in z:\Developing\Visual Studio\Projects\SDammann.WebApi.Versioning\src\SDammann.WebApi.Versioning\VersionedApiControllerSelector.cs:line 61
       at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()
  InnerException: 

RouteVersionedControllerSelector breaks helppage

great package for versioning. gets the job done

however, it breaks the helppage (Microsoft.AspNet.WebApi.HelpPage) in several ways.

RouteVersionedControllerSelector : no routes are shown at all

VersionHeaderVersionedControllerSelector: routes show a funny Version1.RESOURCENAME URI and clicking gives a 404

2 questions for the AcceptHeaderVersionedControllerSelector

I use AcceptHeaderVersionedControllerSelector system.

I would a default version if a client don't send accept header ?

Is it possible the use a major.minor pattern with AcceptHeaderVersionedControllerSelector or is only possible with Major digit.

Thanks

Override VersionPrefix

I'm looking for a way to override the VersionPrefix value found here with a custom one:

SDammann.WebApi.Versioning/VersionedControllerSelector.cs

Line 24: public static readonly string VersionPrefix = "Version";

Do you have any recommendations or thoughts on supporting this?

[HttpRoute] Multiple controllers defined with the same name but differing namespaces

Hello, I'm getting the following error when I try to access and api method:

Multiple types were found that match the controller named 'Grupos'. This can happen if the route that services this request ('api/v{version}/{controller}/{action}/{id}') found multiple controllers defined with the same name but differing namespaces, which is not supported. The request for 'Grupos' has found the following matching controllers: STALoginService.Api.Controllers.Version2.GruposController STALoginService.Api.Controllers.Version1.GruposController

Here is my MapHttpRoute:

config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/v{version}/{controller}/{action}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

Also, here is my project structure:

ApiProject
│
└─── Controllers
│   │
│   └─── Version1
│       │   GruposController.cs
│   │
│   └─── Version2
│       │   GruposController.cs

I learned about this package in the following video: https://www.youtube.com/watch?v=h0ui2KIVcaE and he uses the same class name but in different namespaces.

namespace STALoginService.Api.Controllers.Version1
{
    public class GruposController : ApiController
    {
        ...
    }
}
namespace STALoginService.Api.Controllers.Version2
{
    public class GruposController : ApiController
    {
        ...
    }
}

Does anyone had the same problem? Knows any fix?

Override ControllerSuffix

I would like "Api" to be part of my web api controller class names, not just part of the namespace, to help distinguish MVC from Web Api when reading code. To accomplish this I need to be able to override the controller name suffix.

Example:
/api/v1/Users maps to xxx.Api.Version1.UsersApiController

Is Attribute Routing Supported

@Sebazzz first thank you for creating this package it is exactly what I was looking for.

Currently I am using the following route:

config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/v{version}/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);

My controllers are in the following directory structure:

Controllers
-Version1
--AccountController.cs
-Version2
--AccountController.cs (Inherits from Version1 controller)

Everything works perfectly but I wanted to see if your package supports attribute routing and if it does will it work when the Version2 controller is inheriting from the Version1 controller? I did attempt this but I got some key error which I have seen posted in the issues list before.

I am currently using version 2.8.0 of the package.

Thank you,
Ken

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.