I have similar question as in this questions Default version for API Management
However the question is old, had there been any recent changes in APIM which allows this behaviour where if you dont pass any versions in header/path/query it routes to latest versions
/api/operation?api-version=1.0 <- Goes to 1.0
/api/operation?api-version=1.1 <- Goes to 1.1
/api/operation <- Goes to 1.1 (Here 1.1. is the latest and if no version is pass in URI it should route to latest one(1.1 in this case))
In my case we are using Azure Function for backend API.
Just to add I am not able to comment on existing question :(
Still the same behavior, you have to provide the Api version. When you add a version to a non-versioned API, an Original version will be automatically created and will respond on the default URL so if you do not provide an Api version the original version will respond to that call.
Related
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
We are currently having all our APIs in Azure API Management Portal. The versioning in the API code is handled using the version header. These APIs were deployed into our Production environment mid of Last year. I guess we did not have the versioning concept in the Old API Management Portal and the vendors who are using the APIs which are in Production works without passing the version header (if the version header is not passed, it will fallback to the initial version).
We could see that, currently API Management does have ability to create versions. But, if I create a new version for the existing API – I could see that the existing version (which currently works with or without version header) stops working. It is giving resource not found error. If we go into the API settings page for the Existing version, we could see that the Version Header field is mandatory and not filled.
Is there any way we can default the version header to the initial version through API Management?
This is old but probably worth answering for someone asking in the future.
You can set a header on all API operations in the Azure portal.
Select the API version and then ensure All operations is selected in the list of operations.
Then in the Inbound Processing section click + Add policy.
Set headers is one of the options.
Select that and add the details for the header.
Save and repeat for the other versions you have defined, obviously setting the correct version each time.
Hope this helps.
You may also define passing the version as a header parameter when initially adding the API to API Management as Open API Specification Full definition and then set the Header definition in Versioning scheme.
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
UPDATED QUESTION to clarify more.
I have two servers : wso2greg containing custom artefacts and wso2am (api manager).
The gouvernance register is intended to be used internally (intranet) and some of it's feature are intended to be exposed externally and acceded via it's rest API.
In order to manage wso2greg API accesss, we used an wso2am (api manager) server, where we did define an API that act as a proxy for the wso2greg API.
In our experiments, we found the strange behaviour described below :
Successfully direct calling wso2greg artefact rest api (the exact url is
https://localhost:9443/resource/1.0.0/artifact/_system/governance/myartifact/art1 and i'm following the documentation of this REST API from here https://docs.wso2.com/display/Governance520/Resources+with+REST+API ) using postman. The API reacts as described in the documentation.
Error 500, reported on wso2greg server, when calling the same REST API, but via API manager (using publisher application).
So as a summary :
Directly calling wso2greg rest API woks fine and a got results back
Adding this working API, in wso2am and than calling it gives always error 500.
As extra information:
Tested with other wso2greg REST API , such as "rating" or "comments" and I was able to call it successfully either directly or throw Api manager.
Tried to get information related to default wso2greg artifacts such as restservice, but i got exactly the same pb when (error 500) interagting with API manager.
Working with the last version of both products : wso2greg version 5.2.0 and wso2am version 1.10.0
Please advice, or clarify how could i debug this internal error in wso2greg.
Regards,
I hope your not using G-Reg + APIM feature installed version. I presume your using separate G-reg 5.2.0 and APIM x.x.x. Since your using the second option you can't use G-Reg REST API with APIM, therefore you have to use APIM REST API instead.
Get an API
Description: Get details of a specific API.
URI: http://localhost:9763/publisher/site/blocks/listing/ajax/item-list.jag
URI Parameters: action=getAPI&name=xxx&version=xxx&provider=xxx
HTTP Methods: POST
Example:
curl -X POST -b cookies http://localhost:9763/publisher/site/blocks/listing/ajax/item-list.jag -d "action=getAPI&name=PhoneVerification&version=1.0.0&provider=admin"
Please follow this link to see all the api usage.
Thanks #thusharaK for providing help.
The solution was to add Message Mediation Policies which forces json header on output.
Now i got my correct response from API manager (in fact, i got a binary response in test console and a json response in postman) .
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.