New Features about aspnet-api-versioning HOT 5 CLOSED

Did you have a specific feature[s] in mind? I'm open to suggestions.

I hadn't originally planned on it for v1, but I was able to sneak in support for using conventions to define API versions rather than using attributes only. I expect that to be the last feature included in v1. The feature is already committed and documented on the wiki. I didn't create RC3 release because everything so close to GA for v1, which I expect within the next few days. If there's a desire publish one more release before GA, I'll support it.

If you have additional suggestions or ideas, I'm happy to spark up a discussion and queue up appropriate work. I expect there to be several requests or suggestions from the community over time.

from aspnet-api-versioning.

I was trying to add the package on my projects, but I notice we have many ways to do this. I have Web API and Core applications. If we have just one package and this package recognize the kind of application and set the configs automatically ?

I really dont know if this is possible on this code, but I already search about how to do this before comment here and I would like to discuss about it and I think this can be possible.

I think will be a very usefull feature to this wonderful project!

Congratulations to super helpfull project.

Thanks for attention and I hope we can work together to improve this!

Thanks for attention and I hope we can work together to improve this!

from aspnet-api-versioning.

I agree that it would be ideal to have one package for ASP.NET Web API and ASP.NET Core, but they are just too different. I don't really think there is a way to make them both work in a single NuGet package. I carefully selected the package identifiers so that it would be easy to track down which package to use, for which platform.

The current implementations of this project do not expect to use both ASP.NET Web API and ASP.NET Core simultaneously in the same project, but I believe that ASP.NET Core does support this scenario. If that's your situation, it's worth investigating whether it would be possible to add this support through a new library and package that provides a compatibility shim. This would likely require hooking into the routing pipeline. The current design does not change or alter the routing infrastructure at all; it simply lets routing do its thing and disambiguates duplicate routes by API version. I'm not currently familiar with how the ASP.NET Core router decides which requests to route to Web API or not. The API versioning hook would likely have to be somewhere near that decision point. If this is something you're interested in pursuing, I think it's reasonable to queue up an item to investigate the feasibility in the next release.

If you have a mix of both platforms, but hosted separately, this is a considered scenario, but the libraries can't help you actually do the routing or dispatching. A service can advertise that it supports an API version that it doesn't actually implement. In order to implement this behavior across your services, you'd need a gateway that understands how to dispatch different API versions to different internal endpoints.

For example:

ASP.NET Web API

[ApiVersion( "1.0" ), ApiVersion( "2.0" ), AdvertiseApiVersions( "3.0" )]
public class MyController : ApiController { /* omitted */ }

ASP.NET Core

[ApiVersion( "3.0", AdvertiseApiVersions( "1.0", "2.0" )]
public class MyController : Controller { /* omitted */ }

Now you just need a simple gateway that can transfer the request to the correct web application behind the scenes:

If you enable the ReportApiVersions option, then both controllers will indicate that they support versions 1.0, 2.0, and 3.0, even though they are hosted in different applications. Unless you are hosting both platforms in the same website or application, I'm not sure there is a generic way to create a gateway that can support this; however, I'm open to ideas. The routing required to achieve this occurs at a level above either of the ASP.NET platforms.

from aspnet-api-versioning.

I have the both scenarios that you mention. I really think we can talk about this and queue up an item to investigate the feasibility in the next release(If Can I help on this step, please, contact me), because This really will improve the ways to use this project and will help a lot of developers to use on their mixed application.

On my separated hosted application I will use the solution that you provide above. Thanks for your help and your attention.

I will waiting for next release. If you need me, please let me know.

from aspnet-api-versioning.

There's a possibility that mixing ASP.NET Core and Web API in the same source project is already supported. I'm going to close out this issue because I've queued up #33 to investigate. If necessary, I'll spin up new work to add support for mixed application models. In either case, I'll add a new sample project that uses the Web API back-compat shim so there is an example of what's required to make it work.

Implementing a gateway between multiple web hosts is not something I think can be solved by any of these libraries. If you come up with a working, repeatable solution, please do share. At a minimum, we can add it to the wiki as an advanced topic that others may be able to use for guidance for their services.

from aspnet-api-versioning.