I am experimenting with Azure Functions and stumbled upon concept that I don't really know how to implement properly.
I have Serverless REST Api with Azure functions which contains different endpoints. Only one of this endpoint is meant to be public aka for customers (e.g. GET /api/items) but it also contains different endpoints that need to be triggered only from code like /api/items/sync, /api/items/external and similar. For now I have HTTP Trigger that makes request to /api/items/sync but this endpoint is also available for others aka no restrictions. I know that Azure Functions has Function & Master Keys. Is there a way how to limit these endpoints so they would work only if called from Azure Functions (Like HTTP Trigger) ?
I've received answer from "Azure Architect" slack. Azure has API Management Service which allows to secure certain endpoints and is probably the best way how to handle Azure Functions (and not only them) endpoints for public. What I've done is limited my Serverless API (Azure Function REST API) to "Function" auth type and added API Management service with appropriate route. So my Azure Function is now accessible through API Management Service and Azure Functions endpoints are not explicit.
Related
I would like to connect a Xamarin Forms app to a cloud DB and submit queries (or updates, etc) to the DB via some sort of REST API, where the info passed to the DB is a query, not and endpoint.
I'm seeing plenty of documentation on using various packages to communicate via endpoints, which means I would have to setup those endpoints on my cloud DB. But I don't see anything on using freeform queries.
I realize that in the long run, free form queries are not going to be as efficient. But they would sure make dev & debugging easier. Is there a way to do this ?
Which cloud service are you using? If it's AWS, check out Lambda. In Azure, Azure Functions is Equivalent. You can use that to create a serverless endpoint.
I have multiple API's which I have exposed it via Azure API Management.
I am using one instance for across various environments. So currently I am adding / updating the API's / operations manually. Also I am setting cache, rewrite url for few of these operations. But now managing these are becoming a bit of too much work.
Is there a way, when any operation contracts changes in an API, I can then build / refresh the APIM and also setup the cache, re-write url, policies etc without manual intervention in APIM?
You can consider use Swagger, the OPEN API in Azure to control the data flow with Azure API policy for security and using Azure provided REST API to provision the APIm service and use the App Service to build the backend.
General Concept Flow
AGW <> APIM <> API <> App Service
I have created some APIs in API management layer, which are essentially proxies between the calling client and an underlying web api.
I did this by importing the swagger file of the underlying API, and then adding the newly created API to a Product, repeating this for each separate proxy that I needed. This means then that the underlying API could be called but not without the subscriber key of the product that the newly created API was attached to.
Is it possible to do something similar with API apps, i.e. creating API apps using just the swagger file from the underlying API in the azure portal, that act as proxies between the calling client and an underlying web api (as below)?
Do you mind expanding on why do you need to have API Apps acting as proxies?
I am not aware of such capability for API Apps specifically. There are Swagger-based code generation tools available, for example on http://swagger.io/open-source-integrations/. So perhaps you will be able to find something that would work for you.
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)