Spectral rules to check conformance to Azure API Guidelines
Перейти к файлу
Mike Kistler 0dcf381738 Fix some audit warnings 2024-06-18 07:30:11 -07:00
.github/workflows Create codeql.yml 2023-07-01 08:44:35 -05:00
.vscode Added test case and .vscode setting 2022-01-20 06:35:02 -08:00
docs Add az-put-request-and-response-body rule with test and docs 2024-06-18 06:58:02 -07:00
functions Replace oas2-unused-definition with az-unused-definition 2024-06-18 06:58:33 -07:00
test Replace oas2-unused-definition with az-unused-definition 2024-06-18 06:58:33 -07:00
.eslintrc.js Add naming-convention rules for datetime and boolean 2023-08-22 06:37:58 -05:00
.gitignore Minor refactor of spectral.yaml 2021-09-07 16:32:16 -05:00
.markdownlint.json Initial ruleset for Azure API Guidelines 2021-09-06 20:26:20 -05:00
CODE_OF_CONDUCT.md CODE_OF_CONDUCT.md committed 2021-09-01 06:58:09 -07:00
CONTRIBUTING.md Document coding style and conventions in CONTRIBUTING.md 2023-01-31 07:40:50 -06:00
LICENSE LICENSE committed 2021-09-01 06:58:09 -07:00
README.md Update README.md 2022-01-11 11:12:42 -05:00
SECURITY.md SECURITY.md committed 2021-09-01 06:58:11 -07:00
SUPPORT.md Initial ruleset for Azure API Guidelines 2021-09-06 20:26:20 -05:00
openapi-style-guide.md Improve style and checks for operationIds 2022-11-30 08:12:03 -06:00
package-lock.json Fix some audit warnings 2024-06-18 07:30:11 -07:00
package.json Add naming-convention rules for datetime and boolean 2023-08-22 06:37:58 -05:00
spectral.yaml Improve az-patch-path rule 2024-06-18 07:03:58 -07:00

README.md

Azure API Style Guide

This repository contains a Style Guide for OpenAPI definitions of Azure services. The Style Guide is a companion to the Azure API Guidelines, the OpenAPI 2.0 specification, and the OpenAPI 3.1 specification.

The repository also contains a Spectral ruleset to check an API definition for conformance to the Azure API Guidelines and this Style Guide.

NOTE: It is highly recommended that you leverage the Spectral rule set. Azure service teams have found Spectral to be very useful identifying many common mistakes that affect the overall quality of their Open API documentation. It's one of the first things the API Stewardship Board turns to when revieing an API specification.

However, the errors, warnings, and info messages identified by Spectral should be evaluated in the context of your service, and using your judgement. If you have any questions, concerns, or comments, please don't hesitate to start a discussion in the API Stewardship Teams Channel.

How to use the Spectral Ruleset

Dependencies

The Spectral Ruleset requires Node version 14 or later.

Install Spectral

npm i @stoplight/spectral-cli -g

Usage

You can specify the ruleset directly on the command line:

spectral lint -r https://raw.githubusercontent.com/azure/azure-api-style-guide/main/spectral.yaml <api definition file>

Or you can create a Spectral configuration file (.spectral.yaml) that references the ruleset:

extends:
  - https://raw.githubusercontent.com/azure/azure-api-style-guide/main/spectral.yaml

Example

spectral lint -r https://raw.githubusercontent.com/azure/azure-api-style-guide/main/spectral.yaml petstore.yaml

Using the Spectral VSCode extension

There is a Spectral VSCode extension that will run the Spectral linter on an open API definition file and show errors right within VSCode. You can use this ruleset with the Spectral VSCode extension.

  1. Install the Spectral VSCode extension from the extensions tab in VSCode.
  2. Create a Spectral configuration file (.spectral.yaml) in the root directory of your project as shown above.
  3. Set spectral.rulesetFile to the name of this configuration file in your VSCode settings.

Now when you open an API definition in this project, it should highlight lines with errors. You can also get a full list of problems in the file by opening the "Problems panel" with "View / Problems". In the Problems panel you can filter to show or hide errors, warnings, or infos.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

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

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.