I am new to Azure API Manager, I have used Apigee Edge before where you can store each api proxy code in either git or SVN. But in Azure I am not sure how each API that is exposed via the gateway is stored. I can see there is a repository for the whole API Manager instance. Does that mean all the APIs are bundled to the same Gateway Instance and stored there?
I am planning to build a CI/CD pipeline to create the APIs in the API Manager for that I need to understand how the APIs code will be stored.
Your help is appreciated. Thanks.
Besides the GIT repository for the apimanagement instance, you can fetch it in form of ARM templates. Refer this blog.
https://azure.microsoft.com/en-in/blog/build-a-ci-cd-pipeline-for-api-management/
Related
We have a requirement where we need to have multiple versions of the same API with few changes in it, but we cannot change the URI whatsoever.
URI versioning : api.example.com/v1/resource
Domain versioning : apiv1.example.com/resource
(Request) parameter versioning: GET /something/?version=0.1 HTTP/1.1
In these example, we might have to change or add version numbers in the URI.
Is there anyway through openshift to do API versioning and not change the URL.?
You'd have to look at Red Hat's API Management solutions.
If you are on OpenShift Dedicated, there are some bundled entitlements of the hosted Red Hat OpenShift API Management. If you are on self-managed OpenShift, you'd want to look at 3Scale API Management. Essentially the same product/features, just managed vs. not.
I have some params in Remote Config that I want to update from the Google Cloud Functions.
Should I use the Remote Config API when both Cloud Functions and Remote Config belong to the same account or project?
I am asking because Cloud Functions can directly import the data from Firestore without any authentication and API.
Remote Config provided the RESTful APIs to update the parameters or template.
You don't have to call them from a Google Cloud function. But calling them from a Google Cloud function or even Firebase Cloud function is definitely workable.
You can even call the RESTful APIs from postman or some other tools once you set up the call properly.
Check more details here: https://firebase.google.com/docs/reference/remote-config/rest
With Remote Config backend APIs, you could use Remote Config with Cloud Functions for Firebase, changing values in your app based on events that happen server-side. For example, you can use Remote Config to promote a new feature in your app, and then turn off that promotion automatically once you detect enough people have interacted with the new feature.
Using the Remote Config REST API or the Admin SDKs described in this guide, you can bypass managing the template in the Firebase console to directly integrate Remote Config changes into your own processes.
As described here, Cloud Functions can be triggered in response to changes in Firebase Remote Config in the same Cloud project as the function. This makes it possible to change the behavior and appearance of your app without publishing an app update.
We are using Azure API Management where is supporting WebSocket, but we need 2 different endpoint routes for it, because you can`t create route to your API:
http(s)://{base_url} and ws(s)://{base_url},
you must add difference by using suffix, like :
http(s)://{base_url}
ws(s)://{base_url}/{suffix}
or
http(s)://{base_url}/{suffix}
ws(s)://{base_url}
How we can configure same endpoits ?
During the WebSocket passthrough the client application establishes a WebSocket connection with the API Management Gateway
Check for the steps in adding WebSocket API to APIM here.
Make sure we follow below limitations:
WebSocket APIs are not supported yet in the Consumption tier.
WebSocket APIs are not supported yet in the self-hosted gateway.
Azure CLI, PowerShell, and SDK currently do not support management operations of WebSocket APIs
Refer to this SO thread in including two endpoints for same URL in backend, thanks to Hury for great explanation. Though it is for functions app, but the process is similar.
It seems that this page contains all the functionality that Azure CLI supports in regard to Azure API Management. But it doesn't show how to manage entities such as users, products, certificates, subscriptions, and APIs using Azure CLI.
Does Azure CLI lack these functionalities or is there a way to manage those entities using Azure CLI? Can Azure CLI be considered as a replacement for ARM templates in the case of APIM?
Azure CLI is missing those. Please raise on aka.ms/apimwish
According to my research, the Azure CLI API management command is in preview. SO it will miss some commands. For more details, please refer to the document. So if you want to manage Azure API management entities such as users, products, certificates, subscriptions, and APIs, I suggest you use Azure PowerShell to do that : https://learn.microsoft.com/en-us/powershell/module/az.apimanagement/?view=azps-3.0.0.
The Azure CLI currently seems to support this, see here for Microsoft docs. Make sure you upgrade your CLI to the latest version to be able to leverage this.
To get the CLI docs:
az apim --help
I have an ASP.NET Core REST API Service hosted on an Azure Web App. I own its source code and I can change it if required.
I am planning to publish REST API Service with Azure API Management.
I am adding Azure AD authentication to the Azure API Management front. So, the API management front is secured. All the steps are is described here.
All good so far. Here is the question (or challange?) :
Considering that my backend REST API Service is hosted on Azure and publicly accessible, how do I protect it against the request calls other than the API Management Calls?
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
A link to a code sample or online documentation would be a great help.
Update
While there are some overlaps with the follwoing question:
How to prevent direct access to API hosted in Azure app service
... part of this question is still outstanding:
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
You can enable static IP restriction on your WebApp to only allow incoming traffic from the VIP of your APIM Service facing ( keep in mind in some specific scenarios , the VIP may change and will be required to update the whitelist again).
Clients ==> AAD==> VIP APIM Service <==> (VIP APIM allowed) Web App
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions