You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 23, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: README.md
+2-1Lines changed: 2 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ The proposed approach is illustrated in the below picture.
28
28
29
29
In this example, there are two deployment environments: Development and Production, each has its own API Management instance. API developers have access to the Development instance and can use it for developing and testing their APIs. The Production instance is managed by a designated team called the API publishers.
30
30
31
-
The key in this proposed approach is to keep all API Management configurations in Azure [Resource Manager templates](https://docs.microsoft.com/azure/azure-resource-manager/resource-group-authoring-templates). These templates should be kept in a source control system. We will use GIT throughout this example. As illustrated in the picture, there is a Publisher repository that contains all configurations of the Production API Management instance in a collection of tempaltes.
31
+
The key in this proposed approach is to keep all API Management configurations in Azure [Resource Manager templates](https://docs.microsoft.com/azure/azure-resource-manager/resource-group-authoring-templates). These templates should be kept in a source control system. We will use GIT throughout this example. As illustrated in the picture, there is a Publisher repository that contains all configurations of the Production API Management instance in a collection of templates.
32
32
33
33
***Service template**: contains all the service-level configurations of the API Management instance (e.g., pricing tier and custom domains).
34
34
***Shared templates**: contain shared resources throughout an API Management instance (e.g., groups, products, loggers).
@@ -40,6 +40,7 @@ API developers will fork the publisher repository to a developer repository and
40
40
We realize there are two challenges for API developers when working with Resource Manager templates:
41
41
42
42
* First, API developers often work with [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification) and may not be familiar with Resource Manager schemas. Authoring templates manually might be an error-prone task. Therefore, we created a utility tool called [**Creator**](./src/APIM_ARMTemplate/README.md#Creator) to automate the creation of API templates based on an Open API Specification file. Optionally, developers can supply API Management policies for an API in XML format. Basically, the tool inserts the Open API specification and policies into a Resource Manager template in the proper format. With this tool, API developers can continue focusing on the formats and artifacts they are familiar with.
43
+
43
44
* Second, for customers who have already been using API Management, another challenge is how to extract existing configurations into Resource Manager templates. For those customers, We have created another tool called [**Extrator**](./src/APIM_ARMTemplate/README.md#extractor) to help them generate templates by extracting configurations from their exisitng API Management instances.
44
45
45
46
Once API developers have finished developing and testing an API, and have generated the API template, they can submit a pull request to merge the changes to the publisher repository. API publishers can validate the pull request and make sure the changes are safe and compliant. For example, they can check if only HTTPS is allowed to communicate with the API. Most of these validations can be automated as a step in the CI/CD pipeline. Once the changes are approved and merged successfully, API publishers can choose to deploy them to the Production instance either on schedule or on demand. The deployment of the templates can be automated using [Azure Pipeline](https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops), [PowerShell](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy), [Azure CLI](Azure-cli-example.md) or other tools.
"policyContent": "[concat('<!--\r\n IMPORTANT:\r\n - Policy elements can appear only within the <inbound>, <outbound>, <backend> section elements.\r\n - Only the <forward-request> policy element can appear within the <backend> section element.\r\n - To apply a policy to the incoming request (before it is forwarded to the backend service), place a corresponding policy element within the <inbound> section element.\r\n - To apply a policy to the outgoing response (before it is sent back to the caller), place a corresponding policy element within the <outbound> section element.\r\n - To add a policy position the cursor at the desired insertion point and click on the round button associated with the policy.\r\n - To remove a policy, delete the corresponding policy statement from the policy document.\r\n - Position the <base> element within a section element to inherit all policies from the corresponding section element in the enclosing scope.\r\n - Remove the <base> element to prevent inheriting policies from the corresponding section element in the enclosing scope.\r\n - Policies are applied in the order of their appearance, from the top down.\r\n-->\r\n<policies>\r\n <inbound>\r\n <base />\r\n <set-backend-service base-url=\"https://api.apis.guru/v2/\" />\r\n <rewrite-uri template=\"/metrics.json\" />\r\n </inbound>\r\n <backend>\r\n <base />\r\n </backend>\r\n <outbound>\r\n <base />\r\n </outbound>\r\n <on-error>\r\n <base />\r\n </on-error>\r\n</policies>')]"
"policyContent": "[concat('<!--\r\n IMPORTANT:\r\n - Policy elements can appear only within the <inbound>, <outbound>, <backend> section elements.\r\n - Only the <forward-request> policy element can appear within the <backend> section element.\r\n - To apply a policy to the incoming request (before it is forwarded to the backend service), place a corresponding policy element within the <inbound> section element.\r\n - To apply a policy to the outgoing response (before it is sent back to the caller), place a corresponding policy element within the <outbound> section element.\r\n - To add a policy position the cursor at the desired insertion point and click on the round button associated with the policy.\r\n - To remove a policy, delete the corresponding policy statement from the policy document.\r\n - Position the <base> element within a section element to inherit all policies from the corresponding section element in the enclosing scope.\r\n - Remove the <base> element to prevent inheriting policies from the corresponding section element in the enclosing scope.\r\n - Policies are applied in the order of their appearance, from the top down.\r\n-->\r\n<policies>\r\n <inbound>\r\n <base />\r\n <set-backend-service base-url=\"https://api.apis.guru/v2/\" />\r\n <rewrite-uri template=\"/metrics.json\" />\r\n </inbound>\r\n <backend>\r\n <base />\r\n </backend>\r\n <outbound>\r\n <base />\r\n </outbound>\r\n <on-error>\r\n <base />\r\n </on-error>\r\n</policies>')]"
0 commit comments