Versioning with WebAPI .Net Core does not work as expected - asp.net-core

I am trying to introduce URL versioning into my .Net Core WebAPI application. I am also using Swagger web tools for ease of use for users.
Now, while trying to introduce versioning into my application, I referenced the docs here: https://github.com/Microsoft/aspnet-api-versioning/wiki/New-Services-Quick-Start#aspnet-core
Now, I made following code changes into my code:
Startup.cs/ConfigureServices I added code below:
services.AddApiVersioning(options => {
options.AssumeDefaultVersionWhenUnspecified = true;
});
Now, my controller annotations before any kind of versioning was added, looked like below:
[Produces("application/json")]
[Route("api/controllerName")]
and produces a URL which looks like something below:
http://localhost:12003/swagger/#!/Workspace/GetAll
Now, I added annotations below to enable api versioning:
. [ApiVersion("1.0")]
[Produces("application/json")]
[Route("api/v{version:apiVersion}/workspace")]
and now when I click on the same method listed in my swagger UI
the url looks like below:
http://localhost:12003/swagger/#!/controllername/ApiV_versionGetAll
While what I was expecting was something like:
http://localhost:12003/swagger/#!/controllername/V1.0/GetAll
Also on my swagger it is now asking me explicitly about entering version number. So I think my question boils down to two major points:
How I can I fix my URL? and what am I doing wrong?
Why is swagger now asking me to enter version number in API UI when I have explicitly stated that the version is going to be 1.0 in the annotation of the controller?

What you are missing is the complementary package for API versioning that supports an API version-aware API Explorer:
https://www.nuget.org/packages/Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer
Install-Package Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer
The API Explorer is how Swagger generators like Swashbuckle do all their work. The source and links are also available in the API versioning repo.
To achieve the result you want, you need to configure API version substitution in the URL:
services.AddMvcCore().AddVersionedApiExplorer( options => options.SubstituteApiVersionInUrl = true );
Note: that the call the AddMvcCore() is no longer required in API Versioning 3.0+
Documentation and samples are available in the official API versioning repo. I recommend reviewing the API Documentation wiki topic:
https://github.com/Microsoft/aspnet-api-versioning/wiki/API-Documentation
The accepted answer extends this package, which is fine as long as it stay up-to-date with the flavor of API versioning you are using. API Versioning always ships compatible API Explorer extensions on every release.

Setting up api versioning with swagger is indeed a tricky thing as it is lot's of pieces that need to be setup correctly.
Luckily for us, there's a great nuget packages called SwashbuckleAspNetVersioningShim which solves this in an excellent way.
Add it
Install-Package SwashbuckleAspNetVersioningShim -Version 2.2.1
Then follow the readme here

Related

Generating OpenAPI definitions and documentation for an existing flask project

I'm trying to integrate an existing flask app with OpenAPI (Swagger), to generate its documentation and use Swagger UI. How should I do this?
The best solution (expected behaviour with least changes) for me was to use connexion, and use OpenAPI Specifications to replace the routes layer. Instead of using Flask "directly", a connection app was created.
app = connexion.App(__name__, specification_dir='swagger/')
app.add_api('my_api.yaml')
app.run(port=8080)
https://github.com/zalando/connexion

How to add remote issue link in jira-rest-api

I've got a program which creates JIRA issues using the jira-rest-api supported by Atlassian.
What I'd like to do is to create a link within the issue to an external URL (actually a presigned Amazon S3 link).
At the REST level this should be doable with a POST request to the Jira api to create a remoteLink. However I cannot find methods in the client APIs or a RemoteLink dto in the Java library.
Nor does the Java library appear to give any access to lower level REST handlers.
Now, I could set up my own REST handling code, going right back to the endpoint URL and authentication, but that's messy, when most of the code the code should already be there. Also I can't clearly see which json fields are required, and which not can be left to the API.
Am I overlooking something obvious in the documentation? I can't even seem to locate source for the client implementation, only the interface layer.
My current code is using version 3.0.6 of the api, but I've just checked v4 (which seems to be the latest on offer) and there's still no RemoteLink support.
Have you tried with these?
Server: https://docs.atlassian.com/software/jira/docs/api/REST/7.6.1/?_ga=2.26380925.1321063199.1523351418-1788196903.1491202928#api/2/issue-deleteRemoteIssueLinkById
Cloud: https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-issue-issueIdOrKey-remotelink-linkId-delete

OpenAPI or swagger.json auto discovery

Is there any spec or convention on URL where one should place swagger.json (or whatever name it is agreed) so that public API of my site can be automatically discovered?
Updated 19 April 2017: The OpenAPI Wiki answer I gave previously is "for a very very very old version of the spec". The same source states that for 2.0 the standard is swagger.json, for 3.0 it changes to openapi.json.
Original answer:
The OpenAPI Wiki recommends using an /api-docs endpoint, at
least for server APIs. I've seen several sites in the wild that use
that, and it's our shop standard.
Hope that helps.
How about serving the Swagger JSON in an HTTP response body, in response to an OPTIONS request for the URL / ?
This is specifically permitted by the relevant RFC.
Further, consider implementing HATEOAS, as strongly advocated by Roy Fielding.
Okay. OpenAPI 3.0 still lacking auto-discovery mechanism, I try to propose a scheme based on some things that were already working:
https://example.com/.well-known/schema-discovery is a JSON document pointing to array of available schemas:
[
{
"schema_url": "/openapi.json",
"schema_type": "openapi-3.0"
},
{
"schema_url": "/v2/openapi.json",
"schema_type": "openapi-3.0"
}
]
If there is only one version of API, then https://example.com/openapi.json should be enough.
HTTP Headers. I remember somebody from Google proposed HTTP header for pointing to API. If you can find or remember it, please tell me.

Using Rally SDK 2.0p4: What should I do about 'Deprecated' warnings in the service responses?

On the Rally dev site, the 2.X Apps SDK seems to be the latest. And that is what I am using:
<script type="text/javascript" src="https://rally1.rallydev.com/apps/2.0p4/sdk-debug.js" ></script>
I am using the data model stuff, from the SDK, i.e., Rally.data.ModelFactory.getModel and Model.load
It works fine, but I notice the following message coming back inside the service responses:
"Warnings": ["Start position 401 is past the end of results.", "API status is Deprecated and will become Not Supported on 10/26/2013"],
Why is it calling a deprecated version of the service?
More text from the response that might be helpful:
Ext.data.JsonP.callback32({"QueryResult": {"_rallyAPIMajor": "1", "_rallyAPIMinor": "37", "Errors": [], "Warnings":...
A sample request that the JavaScript SDK seems to be sending to the service:
https://rally1.rallydev.com/slm/webservice/1.37/Defect.js?_dc=1379957135087&_method=GET&start=401&pagesize=200&order=FormattedId%20DESC%2CObjectID&query=(%20(%20(%20(%20(%20(%20(%20(%20(%20ScheduleState%20!%3D%20%22Accepted%22%20)%20AND%20(%20ScheduleState%20!%3D%20%22Released%22%20)%20)%20AND%20(%20ScheduleState%20!%3D%20%22Completed%22%20)%20)%20AND%20(%20State%20!%3D%20%22Duplicate%22%20)%20)%20AND%20(%20State%20!%3D%20%22Can%27t%20Reproduce%22%20)%20)%20AND%20(%20State%20!%3D%20%22Not%20a%20Bug%22%20)%20)%20AND%20(%20State%20!%3D%20%22Closed%22%20)%20)%20AND%20(%20State%20!%3D%20%22Fixed%22%20)%20)%20AND%20(%20Release%20!%3D%20%22%2Frelease%2F6468789462%22%20)%20)&fetch=FormattedId%2CName&includePermissions=true&project=%2Fproject%2F6266786459&projectScopeUp=false&projectScopeDown=true&jsonp=Ext.data.JsonP.callback32
The latest AppSDK 2 is AppSDK 2rc1. It is using the latest version of WS API v2.0.
However depending on the code more or less extensive refactoring may be needed to go from 2.0p4 to 2.0rc1. Charts in rc1 and collections in WS API v2.0 are examples where more expensive changes to the existing 2.0p4 or 2.0p5 code will be needed.
Having said that, I believe nothing will happen on 10/26/2013, and we will continue to answer customer questions and your apps and customization will continue to function.
Web Services API deprecation policy and last supported dates for each version of API are available here, but as long as you are not using SOAP the immediate effect is not significant, and in the immediate future the warning can be ignored. As of WSAPI 2.0 we are fully discontinuing support for SOAP and XML. It does not mean that existing SOAP custom code will be intentionally broken, but we strongly recommend not to write anything new using SOAP interface.

Autobinding in MVC4 WebApi with Ninject.Extensions.Conventions

In my MVC4 app I'm using Ninject.Extensions.Conventions to autobind all itnerfaces with their implementation using default mechanism:
kernel.Bind(x => x
.FromAssembliesMatching("*")
.SelectAllClasses()
.BindDefaultInterface());
This works great for regular controllers, but doesn't for WebApi controllers. What do I need to change/add?
Ok, I resolved the issue by following this article:
http://www.peterprovost.org/blog/2012/06/19/adding-ninject-to-web-api/
In short: I created my own dependency resolver (as per article) and assigned it to GlobalConfiguration.Configuration.DependencyResolver as suggested by nemesv
There are already a many examples on how to integrate NInject with Web API through the web, using:
DependencyResolver
On ASP.NET website is shown standart way of integration of any DI/IoC with Web API:
http://www.asp.net/web-api/overview/extensibility/using-the-web-api-dependency-resolver
IDependencyResolver.
WebApiContrib project shows how to do it with IDependencyResolver
https://github.com/WebApiContrib/WebApiContrib.IoC.Ninject
Please post more information about your implementation of these resolvers, to be more specific in answer.