I am trying to create api and expose them via APIM. The path of the api that I expect is
baseUrl/v1/Product/Upload.
But when i try to use versioning of APIM, I could only come up with something like
baseUrl/Product/v1/Upload, where Product is API url suffix.
Is there a way in APIM to change the order in which version number is placed in the url path.
Every API Developer will have their own requirement of versioning. So Azure API Management provide several options instead of a single approach to versioning. And Path-based versioning is one of those options.
If you check this Path-based versioning section of Microsoft document then you will find -
When the path versioning scheme is used, the version identifier needs to be included in the URL path for any API requests.
The format of an API request URL when using path-based versioning is as follows.
https://{yourDomain}/{apiName}/{versionIdentifier}/{operationId}
It is recommended to follow this format but if you want to modify it you can use the API Management transformation policies. The rewrite-uri policy converts a request URL from its public form to the form expected by the web service.
Read this Rewrite URL and Policy Expressions in Azure API Management document for more information.
Related
I’m trying to create a Google Sheets add-on which uses an API to the clients own finance system which is deployed on their own web site. The url of the site is configurable so we will only need to deploy a single version of the add-on and all our clients will be able to configure it for their own system.
//getServiceURL() returns the configured URL for the clients system, so https://clientsite/financeapi/
restRequest = UrlFetchApp.fetch(getServiceURL(), params);
The problem I have is that it looks like I need to explicitly reference the urls in the ‘urlFetchWhitelist’ in the appsscript.json file. Otherwise I get the error:-
Exception: Request to https://clientsite/financeapi/blahhh/blahhh failed because the URL has not been whitelisted in the script manifest. (line 510, file "Service")
So I would need to add this to the appsscript.json file.
"urlFetchWhitelist": ["https://clientsite/financeapi/"]
Is there any way round this so that it doesn’t need to be explicitly defined as I don't know these URLs at design time as these are configurable by the client?
If there isn’t I guess we could ask each client what URLs we need to contact and add those to the WhiteList. In which case, is there a limit on the number of whitelisted URLs as we will have hundreds. If we are defining these client URLs could this list be visible to the end user as we can’t have these visible to all users for security reasons.
There seems to be no way to directly bypass this requirement, but I guess you could create web app that would act as a layer between your add-on and the API:
Addon <-> WebApp <-> API
This means that you would only need whitelist the web app's URL and then you can handle any changes to the API URL within the web app with full flexibility.
I managed to configure in APIM a set of policies that do what I need (authentication). The config XML is long and dirty, but the rules should be applied to all APIs that require authentication, so I can just set them on 'All APIs' level. But of course not all APIs require authentication. The idea is to configure them using some kind of flow control policy so that they are applied only if API is tagged. But I didn't found a way how to get the APIs metadata.
So is there a way the read APIs metadata using APIM expressions? Or any other way to achieve the main goal?
Checking https://learn.microsoft.com/en-us/azure/api-management/api-management-policy-expressions#ContextVariables again I see no way to query tag meta information while in a policy. Of course you could query tags for an API over API Management REST API itself on the way but I guess this would increase latency substantially.
For cases like this I would create an API product, put the authentication part into the product's policy and then only assign relevant APIs to this product.
Good Afternoon,
I have a situation where three swagger files will have different resources but they belong to the same domain. And I can't merge them into a single swagger as we have many such scenarios and managing of a single swagger and single api proxy will be a big over head.
For example:
I have 3 apis with the following paths and resources
/supermarket/v1/aisles/{aisleId}/itemcategories
/supermarket/v1/aisles/{aisleId}/itemcategories/{itemcategoryId}/seasonedvegetabletypes
/supermarket/v1/aisles/{aisleId}itemcategories/{itemcategoryId}/seasonedvegetabletypes/{vegetablestypeId}/apples
All the above 3 should be in 3 different swagger files, so I need to create 3 api proxies for the above.
Since the path suffix is same for all of them "/supermaket" the Azure API Manager will not allow to create another api proxy with the same path suffix as it MUST Be unique.
So to achieve this in Apigee Edge (Google Edge) api management product. I will have the basepaths as below
/supermarket/v1
/supermarket/v1/aisles//itemcategories/
/supermarket/v1/aisles//itemcategories/*/seasonedvegetabletypes
so that I can avoid the unique path constraint also achieve creating 3 api proxies.
But the Azure API Manager is not accepting the "wildcard" entries into the API Path Suffix field when creating the API Proxy.
Note:
You may suggest combining the 3 apis into a single swagger file might solve the issue but the example I gave above is only 30% of the swagger and we have many such paths that will fall into a single business domain so we must have them in different swagger files and different api proxies.
We should be in a position to deploy different API Proxies with the same path suffix by allowing wild cards or regex into the API Path Suffix.
Your help to resolve this is highly appreciated. Thanks.
At this point this is a limitation that can't be worked around. The only way to make APIM serve those URIs is to put all of them under single API, which is not what you want, unfortunatelly.
I have 2 different restful api-s, and I would like to use Tyk for gateway.
My plan is to have a common url (like: http://viktorservices) which can towards messages to those two api endpoints.
For example, the first api is a user manager api, and has an endpoint:
GET: http://localhost:8080/usermanager/users
And the other api is a car manager api, and it's endpoint:
GET: http://localhost:8081/carmanager/cars
Is it possible somehow, to upload a Swagger JSON for the Tyk Catalog (For developer portal) to be able to se only one API called: User and Car Manager?
And when I click on "View Documentation" in Tyk's developer site, all of the endpoints from both APIs are visible, grouped by their main API names?
I tried to put the two swagger jsons into one as an array, but then it is not visible on the Developer Site.
I am able to upload the swaggers one by one, but then I will have two API-s on the Dev site of Tyk.
I think the main point here is that developer portal documentation/swagger does not have to correlate with the actual APIs you have. Portal gets organized by catalogues/policies. So you can have multiple internal Tyk APIs, but expose them as the single catalog in Portal, by creating Policy which gives access to both APIs. So, just create new "public" swagger file for documentation purpose, which includes endpoints from both of your internal APIs.
Does it make sense?
I am using Azure API Management to provide API gateway for some APIs. To set up a policy for a particular Api, I have used a Property(Named Value) to restore user metadata and then I assign it into a Variable in incoming request body. When adding a new user I need to add metadata for the new user in to the json. The property value has grown and exceeded the limit now and I cannot add more info to it anymore. I am wondering what the best way is to restore my large metadata in order to be accessible in API Management policy?
Update1:
I have switched the Authentication process from Azure to Auth0 so I can add the user metadata to Auth0 app_metadata and then in Azure policies I validate JWT from Auth0 and obtain token claim(app_metadata) explained in this article. By doing so I can solve the large user metadata (json) issue however this doesn't solve other non-related user metadata stored in other Properties(Named Value) and moreover the API gateway inbound policies are growing and becoming a huge bunch of logic which is not easy to manage and maintain.
At this stage I am looking for a solution to handle all the API gateway inbound policies in a better way and more manageable environment i.e. C#. So my two cents is to implement the API gateway inbound policies in a new .net Api and call this new API in the existing API gateway inbound policies so that it can play a bridge role between Azure API gateway and existing API however I'm still not sure if this is acheivable and whether existing API can be called via new API directly or it should be called via Azure API gateway in some way!
At this point you have to either store it in multiple variables or hardcode it in policy directly.
After more research I ended up with this solution which basically suggests to restore user metadata in Azure Cosmos DB and call Cosmos API in API Management Policy to access to the metadata and also the Cosmos API call can be cached in the policy.