<commit_before># Azure REST API Specifications

## Description

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

## Getting started
If you're a Microsoft employee looking for information about all of the repositories and steps for Azure SDK Libraries Releases, go to the [Azure SDK - Internal Wiki](https://aka.ms/jointhesdk). To get access to the wiki, you need to request access to the [Azure SDK Release Partners](https://aka.ms/azsdk/join/azuresdkpartners) security group. This is a MyAccess group and requests to join will need to be approved by your manager.

External Contributors can read [Getting Started with Azure API Specifications](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/getting-started-with-azure-api-specifications.md).



<!--Please check the [announcements page](https://github.com/Azure/azure-rest-api-specs/wiki/Announcements) for any new updates since your last visit.-->

### Terminology

- **Offerings**, **Skus**, and **Features** - These are distinct entities represented in Eco Manager and Service Tree.  While the Offering/Sku/Feature entities and hierarchy represent the externally marketed product, **service/components** entities in service tree represent corresponding engineering entities that together power these external products.  Refer to [Product Taxonomy](https://dev.azure.com/msazure/AzureWiki/_wiki/wikis/AzureWiki.wiki/40783/Service-Tree-Product-Taxonomy) for details. 

- **Resource Provider** - When a service onboard new functionality onto ARM, it is required to complete [Resource Provider Registration](https://armwiki.azurewebsites.net/rp_onboarding/ResourceProviderRegistration.html).  For existing **Resource Provider to Service Mapping**, refer to [Match resource provider to service](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-services-resource-providers#match-resource-provider-to-service)*


## Directory Structure


The structure of the directory should strictly follow these rules:

1. **Profile**: The profile folder contains the profiles' definition files. The profile definition targets for hybrid applications that could run on Azure Stack general availability versions and Azure Cloud. 

2. **Specification**: This folder is the root folder for all Specs (Management Plane and Data Plane) related documents.

3. **{RP-Name} Folders** - each resource provider should have at least one separate folder. 
    > If multiple folders are required? It depends on the following considerations:
    >
    >   -   An RP folder leads to a separate SDK package. Is it expected to have separate SDK packages for different service/component entities?
    >   -   Service/component entities in one folder share the same versioning cycle. Can service/component entities in one folder share the same version label, and upgrade together in the future?
    >   -   Specification files and AutoRest configuration files in one RP folder are better to refer to files in the same RP folder. Note: Entity type definition that need to be referred cross RP folders should to be placed and maintained under the folder [**common-types**](https://github.com/Azure/azure-rest-api-specs#common-types). 
    >   -   For more considerations, you may consult the reviewer in API design review. To initiate the review, Please submit an [Azure SDK intake questionnaire](https://aka.ms/sdk-apex).

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) . There should be an AutoRest configuration file (`readme.md`) for the RP inside both of these folders when present.
<commit_msg>Fix link README.md link for 'Getting Started with Azure API Specifications' 2th (#19994)<commit_after># Azure REST API Specifications

## Description

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

## Getting started
If you're a Microsoft employee looking for information about all of the repositories and steps for Azure SDK Libraries Releases, go to the [Azure SDK - Internal Wiki](https://aka.ms/jointhesdk). To get access to the wiki, you need to request access to the [Azure SDK Release Partners](https://aka.ms/azsdk/join/azuresdkpartners) security group. This is a MyAccess group and requests to join will need to be approved by your manager.

External Contributors can read [Getting Started with OpenAPI Specifications](https://github.com/Azure/azure-rest-api-specs/blob/main/documentation/Getting%20started%20with%20OpenAPI%20specifications.md).



<!--Please check the [announcements page](https://github.com/Azure/azure-rest-api-specs/wiki/Announcements) for any new updates since your last visit.-->

### Terminology

- **Offerings**, **Skus**, and **Features** - These are distinct entities represented in Eco Manager and Service Tree.  While the Offering/Sku/Feature entities and hierarchy represent the externally marketed product, **service/components** entities in service tree represent corresponding engineering entities that together power these external products.  Refer to [Product Taxonomy](https://dev.azure.com/msazure/AzureWiki/_wiki/wikis/AzureWiki.wiki/40783/Service-Tree-Product-Taxonomy) for details. 

- **Resource Provider** - When a service onboard new functionality onto ARM, it is required to complete [Resource Provider Registration](https://armwiki.azurewebsites.net/rp_onboarding/ResourceProviderRegistration.html).  For existing **Resource Provider to Service Mapping**, refer to [Match resource provider to service](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-services-resource-providers#match-resource-provider-to-service)*


## Directory Structure


The structure of the directory should strictly follow these rules:

1. **Profile**: The profile folder contains the profiles' definition files. The profile definition targets for hybrid applications that could run on Azure Stack general availability versions and Azure Cloud. 

2. **Specification**: This folder is the root folder for all Specs (Management Plane and Data Plane) related documents.

3. **{RP-Name} Folders** - each resource provider should have at least one separate folder. 
    > If multiple folders are required? It depends on the following considerations:
    >
    >   -   An RP folder leads to a separate SDK package. Is it expected to have separate SDK packages for different service/component entities?
    >   -   Service/component entities in one folder share the same versioning cycle. Can service/component entities in one folder share the same version label, and upgrade together in the future?
    >   -   Specification files and AutoRest configuration files in one RP folder are better to refer to files in the same RP folder. Note: Entity type definition that need to be referred cross RP folders should to be placed and maintained under the folder [**common-types**](https://github.com/Azure/azure-rest-api-specs#common-types). 
    >   -   For more considerations, you may consult the reviewer in API design review. To initiate the review, Please submit an [Azure SDK intake questionnaire](https://aka.ms/sdk-apex).

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) . There should be an AutoRest configuration file (`readme.md`) for the RP inside both of these folders when present.

{'fraction_non_alphanumeric': 0.08060886829913964, 'fraction_numerical': 0.004235605559232297, 'mean_word_length': 4.706948640483383, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 17, 'https://': 18, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5156382', 'n_tokens_mistral': 1923, 'n_tokens_neox': 1787, 'n_words': 863}