Azure Function Proxies have limited transformation capabilities on three levels: rewriting of the URI, modification of the HTTP headers and changing the HTTP body. The options for transformations are very basic and focussed on just creating a unified API. Azure API Management on the other hand, has an impressive range of transform capabilities.
These are the main transformation policies:
- Convert JSON to XML - Converts request or response body from JSON to XML.
- Convert XML to JSON - Converts request or response body from XML to JSON.
- Find and replace string in body - Finds a request or response substring and replaces it with a different substring.
- Mask URLs in content - Re-writes (masks) links in the response body so that they point to the equivalent link via the gateway.
- Set backend service - Changes the backend service for an incoming request.
- Set body - Sets the message body for incoming and outgoing requests.
- Set HTTP header - Assigns a value to an existing response and/or request header or adds a new response and/or request header.
- Set query string parameter - Adds, replaces value of, or deletes request query string parameter.
- Rewrite URL - Converts a request URL from its public form to the form expected by the web service.
- Transform XML using an XSLT - Applies an XSL transformation to XML in the request or response body.
Next to these policies, you have the opportunity to write policy expressions that inject .NET C# code into your processing pipeline, to make it even more intelligent.
Azure Function Proxies supports any kind of backend security that can be accomplished through static keys / tokens in the URL or HTTP headers. Frontend-facing, Azure Function Proxies offers out-of-the-box authentication enforcement by several providers: Azure Active Directory, Facebook, Google, Twitter & Microsoft. Azure API Management has many options to secure the frontend and backend API, going from IP restrictions to inbound throttling, from client certificates to full OAuth2 support.
These are the main access restriction policies:
- Check HTTP header - Enforces existence and/or value of a HTTP Header.
- Limit call rate by subscription - Prevents API usage spikes by limiting call rate, on a per subscription basis.
- Limit call rate by key - Prevents API usage spikes by limiting call rate, on a per key basis.
- Restrict caller IPs - Filters (allows/denies) calls from specific IP addresses and/or address ranges.
- Set usage quota by subscription - Allows you to enforce a renewable or lifetime call volume and/or bandwidth quota, on a per subscription basis.
- Set usage quota by key - Allows you to enforce a renewable or lifetime call volume and/or bandwidth quota, on a per key basis.
- Validate JWT - Enforces existence and validity of a JWT extracted from either a specified HTTP Header or a specified query parameter.
These are the main authentication policies:
- Authenticate with Basic - Authenticate with a backend service using Basic authentication.
- Authenticate with client certificate - Authenticate with a backend service using client certificates.
Azure Function Proxies can leverage the App Service networking capabilities, if they are deployed within an App Service Plan. This gives three powerful hybrid network integration options: hybrid connections, VNET integration or App Service Environment. Azure API Management, premium tier, allows your API proxy to be part of a Virtual Network. This provides access to all resources within the VNET, which can be extended to on-premises through a Site-to-Site VPN or ExpressRoute. On this level, both services offer quite similar functionality.
The scope of Azure Function Proxies is really at the application level. It creates one single uniform API, that typically consists of multiple heterogenous backend operations. Azure API Management has more of an organizational reach and typically governs (large parts) of the API's available within an organization. The diagram below illustrates how they can be combined together. The much broader scope of API Management results also in a much richer feature set: e.g. the publisher portal to manage API's, the developer portal with samples for quick starts, advanced security options, the enormous range of runtime policies, great versioning experience, etc…
These are some use cases where Azure Function Proxies was already very beneficial:
- Create a single API that consists of multiple Azure Functions and / or Logic Apps
- Create a pass-through proxy to access on-premises API's, without any coding
- Generate a nicer URL for AS2 endpoints that are hosted in Azure Logic Apps
- Generate a simple URL for Logic Apps endpoints, that works better for QR codes
- Add explicit versioning in the URL of Azure Functions and / or Logic Apps
Azure Function Proxies really has an added value in the modern world of API's that often consist of multiple heterogenous (micro-)service operations. It offers very basic runtime API management capabilities, that reside on the application level.