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.
Related
I've been attempting to utilize the Yahoo API to connect to fantasy sports data. I don't have a web URL to connect to when I attempt to create an app, and everything I've read has mentioned that I should select "Installed Application" to avoid using a URL.
This option is not available to me.
Yahoo Developer Screenshot
On the official documentation this is what I see here
Yahoo Developer Documentation
Not sure if it makes a difference but I'm based out of Canada.
Thanks!
It's hard to find the documentation for it, but what you want is called oob (out of bounds, out of band). To get this to work, the steps are a little different (there is no such thing as installed application from what I'm aware of):
Add oob as one of the redirect uris
Make your normal request to the auth/login uri
This will give you a new page that provides you with a token. At this point, you need to manually use this token when you request the /auth/token uri
This last step just replaces the redirect to https://your-redirect.com/token and you will end up in the same position as before.
Now, you still shouldn't put your client_secret in your application if you plan on releasing it, but if you're using it internally or letting others provide their own secret then you should be good.
If you find the original documentation with the PHP source code, you can follow this flow.
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.
I have a question regarding the possibility to change the backend occ endpoint for the login.
In the default behavior, an auth object is created in local storage.
I changed in the app.module the default login: '/authorizationserver/oauth/token', to a different endpoint (/ourowntestserver/oath/token/test). After the change, the backend-side works as it has before, but on the front-end side, the auth object is not available in the local storage anymore.
In the Spartacus source code I can see an OAUTH_ENDPOINT with the same endpoint '/authorizationserver/oauth/token', used in an open-id-token.service, but I am not sure if that service is responsible for actually saving the token and if I have to extend it in the storefront app along with its store(actions, effects, etc.) too.
Are there any other changes that have to be done for this to work, or am I doing something wrong? Is it possible that the issue could be still back-end related?
Any help would be appreciated. (edited)
I would start by inspecting ngrx actions in devtools. Look for LoadUserToken and LoadUserTokenSuccess and LoadUserTokenFail actions. Look at their payload if everything there looks ok. Maybe the structure of response is different than the one returned from the default hybris OAuth server. Then you might need to create your own effect and handle the response a bit different than we do this by default.
The OAUTH_ENDPOINT is not currently customizable and it is being fixed right now for the 3.0 release. It'll have new auth module structure and allow for easier replacement of OAuth server.
open-id-token.service.ts is only used with Kyma module when you also need apart from access_token the id_token from OAuth server.
I went through the Legacy Lock API Deprecation documentation provided link
I have few clarifications
Its mentioned that by July 16, 2018 deprecated services will be removed.
And the criteria are given to identify whether I will get affected or not, below listed
Use of /usernamepassword/login endpoint directly from applications
Use of /user/ssodata endpoint directly from applications
In my application I have integrated auth0-js and I been using auth0.redirect.loginWithCredentials() function to send the username and password along with connection (database connection).
This function actually calls co/authenticate REST end-point.Does my current implementation needs a migration, will I be affected by services that will be stopped by Jul 16.
Another question:
In the advanced settings of a tenant, its advised to disable the Legacy Lock API option under Migrations (see below image). If I do so I get pre-flighted error which is a CORS issue, any relation between this problem and previous question or how do I solve this issue
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