Azure Resource Manager REST API

The Azure Resource Manager (ARM) REST API is a set of HTTP-based endpoints that allow you to create, read, update, and delete (CRUD) Azure resources. It is the programmatic interface to the Azure Resource Manager, the deployment and management service for Azure. The API is RESTful, meaning it uses standard HTTP methods (GET, PUT, POST, DELETE, PATCH) and returns JSON responses. Every action you perform in the Azure portal, Azure CLI, or PowerShell ultimately calls the ARM REST API.

Before ARM, Azure had a classic deployment model that was less flexible and did not support resource grouping or declarative templates. ARM introduced a unified API that allows you to manage resources as a group, apply policies, and use role-based access control. The ARM REST API provides a consistent way to interact with any Azure resource, regardless of the resource provider (e.g., Microsoft.Compute, Microsoft.Network, Microsoft.Storage).

When you make a request to the ARM REST API, the flow is:

- API Version: Every resource type has a specific API version (e.g., 2023-03-01). You must include the api-version query parameter in every request. Using the wrong version can cause unexpected behavior or errors. - HTTP Methods: - GET: Retrieve resource properties or list resources. - PUT: Create or update a resource (idempotent). - PATCH: Partial update of a resource. - DELETE: Delete a resource. - POST: Perform an action (e.g., start a VM). - Status Codes: - 200 OK: Success. - 201 Created: Resource created. - 202 Accepted: Operation accepted (for async operations). - 204 No Content: Success with no response body. - 400 Bad Request: Invalid input. - 401 Unauthorized: Missing or invalid authentication. - 403 Forbidden: Insufficient permissions. - 404 Not Found: Resource not found. - 409 Conflict: Resource state conflict. - Async Operations: Some operations (like creating a VM) are asynchronous. ARM returns 202 Accepted with a Location header pointing to a status URL. You must poll this URL until the operation completes (status Succeeded or Failed). - Throttling: ARM has rate limits: 12,000 read requests per hour and 1,200 write requests per hour per subscription. Exceeding these limits returns 429 Too Many Requests.

To call the ARM REST API, you need to authenticate. Using Azure CLI, you can obtain a token:

az account get-access-token --resource https://management.azure.com --query accessToken -o tsv

Then, use curl or any HTTP client to make requests. For example, to list all resource groups:

curl -X GET "https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups?api-version=2021-04-01" \
  -H "Authorization: Bearer {token}"

To create a resource group:

curl -X PUT "https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}?api-version=2021-04-01" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{"location": "eastus"}'

To deploy an ARM template:

curl -X PUT "https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Resources/deployments/{deploymentName}?api-version=2021-04-01" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d @template.json

Common errors and their resolutions:

A large e-commerce company uses ARM REST API to deploy their application stack across multiple environments (dev, test, prod) consistently. They have a CI/CD pipeline that triggers a PowerShell script, which calls the ARM REST API to deploy an ARM template. The template includes a virtual network, subnets, network security groups, VMs, and a load balancer. The script uses a service principal with contributor rights on the target resource group. The deployment is idempotent; if a resource already exists, it is updated. The team uses the What-If operation (POST to /deployments/{name}/whatIf) to preview changes before actual deployment. Common issues include API version mismatches (template uses an older version than the resource provider supports) and RBAC permissions (service principal missing write permission on a resource type). They mitigate by using the Azure Resource Graph to validate existing resources before deployment.

A managed services provider (MSP) monitors hundreds of Azure subscriptions for their clients. They built a custom web application that uses ARM REST API to fetch resource metadata (e.g., VM sizes, disk states, tags) every 15 minutes. The app uses multiple service principals, each with Reader role on a set of subscriptions, to avoid throttling. They implemented pagination handling because list operations return only 1000 resources per page (via $top and $skipToken). They also use the ARM REST API to trigger actions like starting/stopping VMs based on schedules. The major challenge is token expiration; they refresh tokens proactively every 50 minutes. They also handle 429 errors by queuing requests and retrying with a 30-second delay.

A financial institution uses Azure Policy to enforce tagging and resource location restrictions. Their compliance team uses ARM REST API to audit resources. They run a daily script that calls the ARM REST API to list all resources and their tags, then cross-references with a database of required tags. Resources missing tags are flagged. They also use the ARM REST API to query Azure Policy states (/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults). Misconfiguration example: a developer created a VM with a deprecated API version, causing the PUT request to fail with 400 Bad Request. The team now validates the API version against a list of supported versions before making calls.