I'm new to APIM and I have created an APIM instance and an API (called Ratings). I have pointed to an Azure function that has a couple of endpoints that work fine.
I need to add two other operations that point to another endpoint like https:///api/GetUser/?userid={_userid}.
I'm a bit confused as to how to take my https://larrys.azure-api.net//??????? and then add the call the the https address.
Any pointers would be appreciated.
Thanks|
L
You can use set-backend-service policy at the operation level and override the API level behavior.
Example: <set-backend-service base-url="base URL of the backend service" />
Related
I have single azure function app. I want to create 2 different API endpoints in Azure APIM. How I can do that?
According to some test, it seems we can't implement the requirement by adding an operation in api management because it will show error message Operation with the same method and URL template already exists.
And if we use some other methods such as clone the operation, it will also fail with 404 error because the URL field will change and can not match the function url.
So I think you can just add another api in your api management to implement the requirement (shown like below screenshot).
The two APIM endpoints should be:
https://huryapim.azure-api.net/huryFun1/HttpTrigger1 and https://huryapim.azure-api.net/huryFun2/HttpTrigger1. Both of them request the same azure function url in backend.
In my APIM policies, I need to do a lookup call to a separate REST Name-Value service and enrich the response.
Is there any way to call external Lookup REST service inside APIM policies?
Sure. Use send-request policy at any scope to make a callout. Later you can access result using policy expressions. https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#SendRequest
First of all I want to use Google Places API for autocomplete. I have created API key and it works fine. I make api calls from client so I need to protect or restrict it. I tried to use HTTP restriction, but it doesn't work with Places API. There are recommendation in the docs to use IP restriction but it requires that some proxy server to make api calls. So which way is right? Do I need proxy server with IP restriction to make api calls? Or is there some way to make secure api calls from client?
Normally, when you are calling the requests from the Client-Side, it should be restricted via HTTP referrers, and IP address restrictions are used when you are calling the requests from the server-side which has a static IP address. If you're calling from the Client-Side and your HTTP restrictions are not working, it will be best to file a support case via https://console.cloud.google.com/google/maps-apis/support in order to open personalized communication channel as this must be an isolated case and might have something to do with your configuration in your GCP console.
I would also recommend to check the sample HTTP restriction below:
example.com
*.example.com
These two will allow your API key to be used in all subdomains and paths in your website.
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.
Is it possible to create a single policy that will forward all Options requests to the backend server? The only way I have figured out how to do this is by creating a new Options operation for each endpoint. That seems like a lot of unnecessary work since I want all options requests to be forwarded to the backend.
How can I create a single policy to forward all Options requests to the backend?
I don't think that is currently possible, so your only options are:
Create a separate OPTIONS operation in each endpoint.
Set up CORS (https://msdn.microsoft.com/library/azure/7689d277-8abe-472a-a78c-e6d4bd43455d#CORS) policy on a product or global level, so that OPTIONS requests would be served by APIM and not forwarded to backend at all.
Actually it is, operation template support wildcard /*
I am trying this, but since our API requires an SubscriptionKey, it is still not working. Since ApiMgmt will return 401 for options request, since browsers dont send the SubscriptionKey header.
Would be nice with the possibility to open single operations...
https://feedback.azure.com/forums/248703-api-management/suggestions/19450117-feature-to-ignore-api-management-subscription-key