Skip to content
This is a clone of azure-rest-api-spec repo. This repo will be used to test automated tooling for swagger to SDK
Branch: dev
Clone or download
Latest commit 4ffb877 Mar 11, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.

Repo Status

Azure REST API Specifications


This repository is the canonical source for REST API specifications for Microsoft Azure.


If you're a spec author looking for information about all of the repositories and steps in the pipeline, go to the adx-documentation-pr repository. Make sure to join the Github Azure organization to get access to that repo.

Latest improvement: Microsoft employees can try out our new experience at OpenAPI Hub - online experience for using our validation tools and finding your workflow.

Please check the announcements page for any new updates since your last visit.

Getting started

Directory Structure

The structure of the directory should strictly follow these rules:

  1. Profile: The profile holder contains the profiles' definition MD files. these files will contain information and references to the snapshots of the RPs' Resource types or Dataplane API versions that represent a specific profile.

  2. Specification: This folder the is root folder for all Specs (Management and Dataplane) related docs.

  3. {RP-Name} Folders - each RP will have a separate folder

  4. 'resource-manager' and 'data-plane' Folders: the RPs can put specs in one of two categories: resource-manager (for ARM resources) and data-plane (for everything else) . The autorest configuration file ( for the RP should be inside this folder

  5. 'preview' and 'stable' Folders: Varying levels of stability exist in our repository. Each API Version folder should be categorized as either still accepting breaking changes, or no longer accepting breaking changes. This is not a direct analog for whether or not an API Version has the "-preview" suffix or not. SDKs that are generated from 'preview' folder items should indicate to their customers in the most idiomatic way that breaking changes may still be coming.

  6. API versions: this folder will be the direct child of the category folder. there will be one such folder per resource type or dataplane service version. This folder will contain the OpenAPI validation Specs (Swaggers previously) and the examples folder.

  7. Examples: the example folder will contain the x-ms-examples files. it will reside under the APIs or Resources' version folders as different APIs or Resource types version can have different examples.

  8. Notes:

    • folder names should be singular (ie, 'profile' not 'profiles' ) -- this removes ambiguity for some non-english speakers.
    • generic folder names should be lower-case
    • proper-name/product name/namespace folders can be PascalCased (ie, "KeyVault")
    • files are whatever case you think is good for your soul.

The structure should appear like so:

|    +---automation
|    |   \---resource-manager
|    |       \---Microsoft.Automation
|    |           \---stable
|    |               \---2015-10-31
|    |                   \---examples
|    +---batch
|    |   +---data-plane
|    |   |   \---Microsoft.Batch
|    |   |       +---stable
|    |   |       |   +---2015-12-01.2.2
|    |   |       |   +---2016-02-01.3.0
|    |   |       |   +---2016-07-01.3.1
|    |   |       |   +---2017-01-01.4.0
|    |   |       |       \---examples
|    |   |       \---preview
|    |   |           \---2017-05-01.5.0
|    |   \---resource-manager
|    |       \---Microsoft.Batch
|    |           +---stable
|    |           |   +---2015-12-01
|    |           |   +---2017-01-01
|    |           |       \---examples
|    |           \---2017-05-01
|    |               \---examples
|    +---billing
|        \---resource-manager
|            \---Microsoft.Billing
|                \---stable
|                |   +---2017-02-27-preview
|                |       \---examples
|                +---preview
|                    \---2017-04-24-preview
|                        \---examples

Currently, the specifications are expected to be in Swagger JSON format

Next steps

The next step in the process after a spec is completed is to generate SDKs and API reference documentation. Go to the Azure Developer Experience guide for more information.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact with any additional questions or comments.

You can’t perform that action at this time.
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.