{"id":21128710,"url":"https://github.com/IBM/openapi-validator","last_synced_at":"2025-07-08T23:33:04.479Z","repository":{"id":37957547,"uuid":"153173690","full_name":"IBM/openapi-validator","owner":"IBM","description":"Configurable and extensible validator/linter for OpenAPI documents","archived":false,"fork":false,"pushed_at":"2025-06-16T14:44:03.000Z","size":9365,"stargazers_count":556,"open_issues_count":18,"forks_count":92,"subscribers_count":21,"default_branch":"main","last_synced_at":"2025-06-27T13:08:40.402Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/IBM.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2018-10-15T19:59:22.000Z","updated_at":"2025-06-27T11:12:48.000Z","dependencies_parsed_at":"2024-03-22T16:46:41.287Z","dependency_job_id":"4536294a-cf95-4e4a-9a8e-eae2e824c54a","html_url":"https://github.com/IBM/openapi-validator","commit_stats":{"total_commits":1194,"total_committers":44,"mean_commits":"27.136363636363637","dds":0.6608040201005025,"last_synced_commit":"fa72e8c601a6cc0a1b93832031660c10966a9f20"},"previous_names":[],"tags_count":454,"template":false,"template_full_name":null,"purl":"pkg:github/IBM/openapi-validator","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IBM%2Fopenapi-validator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IBM%2Fopenapi-validator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IBM%2Fopenapi-validator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IBM%2Fopenapi-validator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/IBM","download_url":"https://codeload.github.com/IBM/openapi-validator/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IBM%2Fopenapi-validator/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":262441698,"owners_count":23311748,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-20T05:01:44.762Z","updated_at":"2025-07-08T23:33:04.472Z","avatar_url":"https://github.com/IBM.png","language":"JavaScript","funding_links":[],"categories":["JavaScript","others"],"sub_categories":[],"readme":"[![Build Status](https://github.com/IBM/openapi-validator/actions/workflows/build.yaml/badge.svg)](https://github.com/IBM/openapi-validator/actions/workflows/build.yaml)\n[![npm-version](https://img.shields.io/npm/v/ibm-openapi-validator.svg)](https://www.npmjs.com/package/ibm-openapi-validator)\n[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)\n[![Gitter](https://badges.gitter.im/openapi-validator/community.svg)](https://gitter.im/openapi-validator/community?utm_source=badge\u0026utm_medium=badge\u0026utm_campaign=pr-badge)\n[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/)\n[![CLA assistant](https://cla-assistant.io/readme/badge/ibm/openapi-validator)](https://cla-assistant.io/ibm/openapi-validator)\n\n# OpenAPI Validator\nThe IBM OpenAPI Validator lets you validate [OpenAPI 3.0.x](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md)\nand [OpenAPI 3.1.x](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md) documents for compliance with the OpenAPI specifications, as well as IBM-defined best practices.\n\n#### Prerequisites\n- Node 16.0.0+\n- NPM 8.3.0+\n\n## Table of contents\n\n\u003c!--\n  The TOC below is generated using the `markdown-toc` node package.\n\n      https://github.com/jonschlinkert/markdown-toc\n\n  You should regenerate the TOC after making changes to this file.\n\n      npm run format-readme-toc\n  --\u003e\n\n\u003c!-- toc --\u003e\n\n- [Getting Started](#getting-started)\n  * [Ruleset](#ruleset)\n  * [Customization](#customization)\n- [Installation](#installation)\n  * [Install with NPM (recommended)](#install-with-npm-recommended)\n  * [Download an executable binary](#download-an-executable-binary)\n  * [Build from source](#build-from-source)\n    + [Build platform-specific binaries](#build-platform-specific-binaries)\n  * [Container image](#container-image)\n    + [Building your own](#building-your-own)\n- [Usage](#usage)\n  * [Command Syntax](#command-syntax)\n  * [Configuration](#configuration)\n    + [Configuration Properties](#configuration-properties)\n      - [colorizeOutput](#colorizeoutput)\n      - [errorsOnly](#errorsonly)\n      - [files](#files)\n      - [ignoreFiles](#ignorefiles)\n      - [limits](#limits)\n      - [logLevels](#loglevels)\n      - [outputFormat](#outputformat)\n      - [ruleset](#ruleset)\n      - [summaryOnly](#summaryonly)\n      - [produceImpactScore](#produceimpactscore)\n      - [markdownReport](#markdownreport)\n  * [Programmatic Usage](#programmatic-usage)\n- [Validator Output](#validator-output)\n  * [Text](#text)\n    + [Additional Customization](#additional-customization)\n  * [JSON](#json)\n- [Logging](#logging)\n- [Contributing](#contributing)\n- [License](#license)\n\n\u003c!-- tocstop --\u003e\n\n## Getting Started\nThe validator analyzes your API definition and reports any problems within. The validator is highly customizable,\nand supports OpenAPI 3.0.x and 3.1.x documents.\nThe tool also supports a number of rules from [Spectral](https://stoplight.io/open-source/spectral/). You can easily extend the tool with custom rules to meet your specific needs and ensure compliance to your standards.\n\nGet started by [installing the tool](#installation), then [run the tool](#usage) on your API definition.\n\n### Ruleset\nBy default, the validator will use the [IBM Cloud Validation Ruleset](docs/ibm-cloud-rules.md) (npm package `@ibm-cloud/openapi-ruleset`).\nHowever, if the validator detects the presence of any of the standard Spectral ruleset files (`spectral.yaml`, `spectral.yml`, `spectral.json`,\nor `spectral.js`) in the current directory (from which the validator is being run) or in any containing directory within the file system,\nthen that ruleset file will be used instead.\nTo explicitly specify an alternate ruleset, you can use the `-r`/`--ruleset` option (or the `ruleset` configuration property)\nto specify the name of your custom ruleset file.\n\nIf one of the standard Spectral ruleset files are present and you'd like to force the use of the IBM Cloud Validation Ruleset instead,\nyou can use `-r default` or `--ruleset default` (or set the `ruleset` configuration property to the value `'default'`).\n\nDetails about these options are provided below in the [Usage](#usage) section.\n\n### Customization\n\nYou can modify the behavior of the validator for your project to meet your preferred standards. See the [customization documentation](docs/ibm-cloud-rules.md#customization) for more information.\n\n## Installation\nThere are three ways to install the validator: using NPM, downloading a platform-specific binary, or building from source.\n\n### Install with NPM (recommended)\n\n`npm install -g ibm-openapi-validator`\n\nThe `-g` flag installs the tool globally so that the validator can be run from anywhere in the file system. Alternatively, you can pass no flag or the `--save-dev` flag to add the validator as a dependency to your project and run it from your NPM scripts or JavaScript code.\n\n### Download an executable binary\n\nPlatform-specific binary files are packaged with each release for MacOS, Linux, and Windows. See [the releases](https://github.com/IBM/openapi-validator/releases) page to download the executable for your platform. These do not depend on Node.JS being installed.\n\n### Build from source\n1. Clone or download this repository\n2. Navigate to the root directory of this project.\n3. Install the dependencies using `npm install`\n4. Build the command line tool by running `npm run link`.\n\n_If you installed the validator using `npm install -g ibm-openapi-validator`, you will need to run `npm uninstall -g ibm-openapi-validator` before running `npm run link`._\n\n#### Build platform-specific binaries\nIt is also possible to build platform specific binaries from the source code by running `npm run pkg` in the project root directory.  The binaries (lint-openapi-macos, lint-openapi-linux, lint-openapi-windows.exe) will be in the project's `packages/validator/bin` directory.\n\n### Container image\n\nRun the validator with the container image by mounting your API definition.\n\nIf it is named `openapi.yaml` in the current directory, then run:\n```bash\ndocker run \\\n  --rm --tty \\\n  --volume \"$PWD:/data:ro\" \\\n  ibmdevxsdk/openapi-validator:latest \\\n    openapi.yaml\n```\n\nYou should **replace `latest` with a specific tagged version** to avoid any surprises when new releases are published.\n\nFlag and argument syntax is the same as described in [Usage](#usage), but file paths are relative to `/data`.\n\nTo use a custom ruleset named `ruleset.yaml` in the current directory, run:\n```bash\ndocker run \\\n  --rm --tty \\\n  --volume \"$PWD:/data:ro\" \\\n  ibmdevxsdk/openapi-validator:latest \\\n    --ruleset ruleset.yaml \\\n    openapi.yaml\n```\n\n#### Building your own\n\nIf the existing image doesn't suit your needs, you could extend it and build your own.\n\nFor example, to build a validator image with your own custom ruleset package installed, make a `Dockerfile` like this:\n\n```Dockerfile\nFROM ibmdevxsdk/openapi-validator:latest\nRUN npm install -g ${your-ruleset-pkg-here}\n```\n\n## Usage\n### Command Syntax\n```bash\nUsage: lint-openapi [options] [file...]\n\nRun the validator on one or more OpenAPI 3.x documents\n\nOptions:\n  -c, --config \u003cfile\u003e            use configuration stored in \u003cfile\u003e (*.json, *.yaml, *.js)\n  -e, --errors-only              include only errors in the output and skip warnings (default is false)\n  -i, --ignore \u003cfile\u003e            avoid validating \u003cfile\u003e (e.g. -i /dir1/ignore-file1.json --ignore /dir2/ignore-file2.yaml ...) (default is []) (default: [])\n  -j, --json                     produce JSON output (default is text)\n  -l, --log-level \u003cloglevel\u003e     set the log level for one or more loggers (e.g. -l root=info -l ibm-schema-description-exists=debug ...)  (default: [])\n  -n, --no-colors                disable colorizing of the output (default is false)\n  -r, --ruleset \u003cfile\u003e           use Spectral ruleset contained in `\u003cfile\u003e` (\"default\" forces use of default IBM Cloud Validation Ruleset)\n  -s, --summary-only             include only the summary information and skip individual errors and warnings (default is false)\n  -q, --impact-score             compute scores representing the API impact of rule violations and include with the results (default is false)\n  -m, --markdown-report          generate a Markdown file with a report on all validator results (default is false)\n  -w, --warnings-limit \u003cnumber\u003e  set warnings limit to \u003cnumber\u003e (default is -1)\n  --version                      output the version number\n  -h, --help                     display help for command\n```\nwhere `[file...]` is a space-separated list containing the filenames of one or more OpenAPI 3.x documents to be validated.\nThe validator supports OpenAPI documents in either JSON or YAML format, using these supported file extensions:\n```\n.json\n.yaml\n.yml\n```\nAssuming your command shell supports the use of wildcards, you can use wildcards when specifying the names of files to be validated.\nFor example, to run the validator on all `.yaml` files contained in the `/my/apis` directory, you could use\nthis command:\n```bash\nlint-openapi /my/apis/*.yaml\n```\n\nNote that the `-i`/`--ignore` option can be particularly useful when using wildcards because it allows you to skip the\nvalidation of specific files which might otherwise be included in a validation run.\nFor example, to validate all `.yaml` files in the `/my/apis` directory, except for `/my/apis/broken-api.yaml` use the command:\n```bash\nlint-openapi /my/apis/*.yaml -i /my/apis/broken-api.yaml\n```\n\n### Configuration\nIn addition to command-line options, the validator supports the use of a configuration file containing options as well.\nA configuration file can be in JSON, YAML or Javascript format, using these supported extensions: `.json`, `.yaml`, `.yml`, and `.js`.\nIts structure must comply with [this JSON schema](packages/validator/src/schemas/config-file.yaml).\n\nYou can specify the name of your configuration file with the `-c`/`--config` option.  Here's an example:\n```bash\nlint-openapi -c my-config.yaml my-api.json\n```\nwhere `my-config.yaml` might contain the following:\n```yaml\nerrorsOnly: true\nlimits:\n  warnings: 25\noutputFormat: 'json'\nsummaryOnly: true\n```\nThis would be equivalent to this command:\n```bash\nlint-openapi --errors-only --warnings-limit=25 --json --summary-only my-api.json\n```\nWhen using both a configuration file and various command-line options, be aware that the options specified\nvia the command-line will take precendence and override any corresponding properties specified in the configuration file.\n\n#### Configuration Properties\nThis section provides information about each of the properties that are supported within a configuration file.\n\n##### colorizeOutput\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003ecolorizeOutput\u003c/code\u003e configuration property corresponds to the \u003ccode\u003e-n\u003c/code\u003e/\u003ccode\u003e--no-colors\u003c/code\u003e\ncommand-line option. If set to true, then the validator will colorize its output.\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003etrue\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\ncolorizeOutput: false\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"colorizeOutput\": false\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  colorizeOutput: false\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### errorsOnly\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003eerrorsOnly\u003c/code\u003e configuration property corresponds to the \u003ccode\u003e-e\u003c/code\u003e/\u003ccode\u003e--errors-only\u003c/code\u003e command-line option.\nIf set to \u003ccode\u003etrue\u003c/code\u003e, the validator will include only errors in its output, while messages of severity warning,\ninfo or hint will be skipped.\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003efalse\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nerrorsOnly: true\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"errorsOnly\": true\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  errorsOnly: true\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### files\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003efiles\u003c/code\u003e configuration property corresponds to positional command-line arguments (i.e. \u003ccode\u003e[file...]\u003c/code\u003e).\nYou can set this property to the names of the OpenAPI documents to be validated. If any filenames are also entered as positional arguments\non the command-line, they will override any values specified in this configuration property.\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e[]\u003c/code\u003e(empty list)\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nfiles:\n  - file1.json\n  - file2.yaml\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"files\": [\n    \"file1.json\",\n    \"file2.yaml\"\n  ]\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  files: [\n    'file1.json',\n    'file2.yaml'\n  ]\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### ignoreFiles\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003eignoreFiles\u003c/code\u003e configuration property corresponds to the \u003ccode\u003e-i\u003c/code\u003e/\u003ccode\u003e--ignore\u003c/code\u003e command-line option.\nSet this property to the fully-qualified filenames of OpenAPI documents to be excluded from validation.\nThis property can be particularly useful when using wildcards for specifying the OpenAPI documents to be validated,\nbecause it allows you to skip the validation of specific files which might otherwise be included in a validation run.\nFor example, to validate all \u003ccode\u003e.yaml\u003c/code\u003e files in the \u003ccode\u003e/my/apis\u003c/code\u003e directory, except for\n\u003ccode\u003e/my/apis/broken-api.yaml\u003c/code\u003e use the command:\n\u003cpre\u003e\n    lint-openapi /my/apis/*.yaml --ignore /my/apis/broken-api.yaml\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e[]\u003c/code\u003e(empty list)\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nignoreFiles:\n  - /my/apis/file1.yml\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"ignoreFiles\": [\n    \"/my/apis/file1.yml\"\n  ]\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  ignoreFiles: [\n    '/my/apis/file1.yml'\n  ]\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### limits\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003elimits\u003c/code\u003e configuration property corresponds to the \u003ccode\u003e-w\u003c/code\u003e/\u003ccode\u003e--warnings-limit\u003c/code\u003e command-line option.\nUse this property to set the warnings limit.  When validating an OpenAPI document, the validator will compare the number of warnings\nit encounters with the warnings limit.  If the number of warnings exceeds the limit, then an error will be logged and the\nvalidator will return exitCode 1, similar to if actual errors were found. If the warnings limit is set to a negative number,\nthen no warnings limit check will be performed by the validator.\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e{ warnings: -1 }\u003c/code\u003e(warnings limit check disabled)\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nlimits:\n  warnings: 25\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"limits\": {\n    \"warnings\": 25\n  }\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  limits: {\n    warnings: 25\n  }\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### logLevels\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003elogLevels\u003c/code\u003e property is an object that specifies the logging level\n(\u003ccode\u003eerror\u003c/code\u003e, \u003ccode\u003ewarn\u003c/code\u003e, \u003ccode\u003einfo\u003c/code\u003e, or \u003ccode\u003edebug\u003c/code\u003e)\nassociated with each logger within the validator.  It corresponds to the \u003ccode\u003e-l\u003c/code\u003e/\u003ccode\u003e--log-level\u003c/code\u003e command-line option.\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e{ root: 'info' }\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nlogLevels:\n  root: error\n  ibm-schema-description-exists: debug\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"logLevels\": {\n    \"root\": \"error\",\n    \"ibm-schema-description-exists\": \"debug\"\n  }\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  logLevels: {\n    root: 'error',\n    'ibm-schema-description-exists': 'debug'\n  }\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### outputFormat\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eYou can set the \u003ccode\u003eoutputFormat\u003c/code\u003e configuration property to either \u003ccode\u003etext\u003c/code\u003e or \u003ccode\u003ejson\u003c/code\u003e\nto indicate the type of output you want the validator to produce.\nThis property corresponds to the \u003ccode\u003e-j\u003c/code\u003e/\u003ccode\u003e--json\u003c/code\u003e command-line option.\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003etext\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\noutputFormat: json\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"outputFormat\": \"json\"\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  outputFormat: 'json'\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### ruleset\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eYou can use the \u003ccode\u003eruleset\u003c/code\u003e configuration property to specify a custom ruleset to be used by the validator.\nThis corresponds to the \u003ccode\u003e-r\u003c/code\u003e/\u003ccode\u003e--ruleset\u003c/code\u003e command-line option.\n\nBy default, the validator will look for the standard Spectral ruleset files (\u003ccode\u003e.spectral.yaml\u003c/code\u003e, \u003ccode\u003e.spectral.yml\u003c/code\u003e,\n\u003ccode\u003e.spectral.json\u003c/code\u003e, or \u003ccode\u003e.spectral.js\u003c/code\u003e) in the current working directory and\nits parent directories within the filesystem.  If none are found, then the IBM Cloud Validation Ruleset\nwill be used.\n\nIf you want to force the use of the IBM Cloud Validation Ruleset even if one of the standard Spectral ruleset files are present,\nyou can specify \u003ccode\u003e'default'\u003c/code\u003e for the \u003ccode\u003eruleset\u003c/code\u003e configuration property.\n\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003enull\u003c/code\u003e, which implies that a standard Spectral ruleset file will be used (if present),\notherwise the IBM Cloud Validation Ruleset will be used.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nruleset: my-custom-rules.yaml\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"ruleset\": \"my-custom-rules.yaml\"\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  ruleset: 'my-custom-rules.yaml'\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### summaryOnly\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003esummaryOnly\u003c/code\u003e configuration property corresponds to the \u003ccode\u003e-s\u003c/code\u003e/\u003ccode\u003e--summary-only\u003c/code\u003e command-line option.\nIf set to true, the validator will include only the summary section in its output.\n\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003efalse\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nsummaryOnly: true\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"summaryOnly\": true\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  summaryOnly: true\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### produceImpactScore\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003eproduceImpactScore\u003c/code\u003e configuration property corresponds to the\n\u003ccode\u003e-q\u003c/code\u003e/\u003ccode\u003e--impact-score\u003c/code\u003e command-line option. If set to true,\nthe validator will, in addition to reporting individual rule violations, use the\nrule violation data to produce API impact scores based on the categories of usability,\nsecurity, robustness, and cost of evolution. By default, the data demonstrating how\nthe scores are calculated from each rule is displayed. If this option is combined with\nthe \"summary only\" configuration option, only the categorized impact scores are displayed.\nThese scores are useful for \"Automated Quality Screening\". See [this documentation](docs/automated-quality-screening.md)\nfor more information about the purpose of these scores and how they are computed.\n\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003efalse\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nproduceImpactScore: true\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"produceImpactScore\": true\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  produceImpactScore: true\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n##### markdownReport\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cb\u003eDescription\u003c/b\u003e\u003c/td\u003e\n\u003ctd width=25%\u003e\u003cb\u003eDefault\u003c/b\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe \u003ccode\u003emarkdownReport\u003c/code\u003e configuration property corresponds to the\n\u003ccode\u003e-m\u003c/code\u003e/\u003ccode\u003e--markdown-report\u003c/code\u003e command-line option.\nIf set to true, the validator will generate a Markdown file containing a report on all of the validator results,\nincluding the individual rule violations, the impact scores, and the data used to compute the impact scores.\nIt provides a single location to see all of the information produced by the validator.\nA default filename is always used and is based on the name of the API definition file provided to the validator.\nIf a file of the same name already exists, it will be overwritten by default. This is because the primary use-case\nof this feature is publishing reports during CI/CD builds, where a single report will need to be updated frequently.\n\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003efalse\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\u003cb\u003eExamples:\u003c/b\u003e\n\u003ctable border=1\u003e\n\u003ctr\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e.yaml/.yml\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.json\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e.js\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmarkdownReport: true\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\n{\n  \"markdownReport\": true\n}\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\n\u003cpre\u003e\nmodule.exports = {\n  markdownReport: true\n};\n\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n### Programmatic Usage\nWhile the validator does not expose an API for usage within a Node.js program, you can achieve programmatic behavior\nconsistent with the CLI by using the open-source tool [Spectral's Node API](https://meta.stoplight.io/docs/spectral/eb68e7afd463e-spectral-in-java-script)\nand the [IBM OpenAPI Ruleset package](https://www.npmjs.com/package/@ibm-cloud/openapi-ruleset).\nHere is a simple example of what that might look like:\n```js\nconst ibmOpenapiRuleset = require('@ibm-cloud/openapi-ruleset');\nconst { Spectral } = require('@stoplight/spectral-core');\n\nfunction async runSpectral(openapiDocument) {\n  const spectral = new Spectral();\n  spectral.setRuleset(ibmOpenapiRuleset);\n  results = await spectral.run(openapiDocument);\n  console.log(results);\n}\n```\n\n## Validator Output\nThe validator can produce output in either text or JSON format.  The default is `text` output, and this can be\ncontrolled with the `-j`/`--json` command-line option or `outputFormat` configuration property.\n\n**NOTE** The text (i.e. \"human readable\") output is not a part of the tool's contract and may change in a minor\nor patch release. If you are building automation or scripts with this tool, use the JSON output, which is stable\nand subject to semantic versioning.\n\n### Text\nHere is an example of text output:\n```\nIBM OpenAPI Validator (validator: 0.97.5; ruleset: 0.45.5), @Copyright IBM Corporation 2017, 2023.\n\nValidation Results for /my/directory/my-api.yaml:\n\nErrors:\n\n  Message :   Path contains two or more consecutive path parameter references: /v1/clouds/{cloud_id}/{region_id}\n  Rule    :   ibm-no-consecutive-path-parameter-segments\n  Path    :   paths./v1/clouds/{cloud_id}/{region_id}\n  Line    :   332\n\nWarnings:\n\n  Message :   Operation summaries should not have a trailing period\n  Rule    :   ibm-summary-sentence-style\n  Path    :   paths./v1/clouds.post.summary\n  Line    :   46\n\n  Message :   Operation summaries should not have a trailing period\n  Rule    :   ibm-summary-sentence-style\n  Path    :   paths./v1/clouds.get.summary\n  Line    :   93\n\nSummary:\n\n  Total number of errors   : 1\n  Total number of warnings : 2\n\n  Errors:\n   1 (100%) : Path contains two or more consecutive path parameter references\n\n  Warnings:\n   2 (100%) : Operation summaries should not have a trailing period\n```\nAs you can see, any errors detected by the validator are listed first, then\nwarnings, and finally a summary section.\n\n#### Additional Customization\n- The `-s`/`--summary-only` command-line option or the `summaryOnly` configuration property causes only the summary to be displayed.\n- The `-e`/`--errors-only` option or `errorsOnly` configuration property causes only error-level violations to be displayed.\n- The `-q`/`--impact-score` option or `produceImpactScore` configuration property causes the validator to show aggregated impact scores. See the example below:\n\nExample of impact score tables that are appended to the standard output:\n```\n┌────────────────┬───────────┐\n│       category │ max score │\n├────────────────┼───────────┤\n│      usability │   98 /100 │\n│       security │  100 /100 │\n│     robustness │   97 /100 │\n│      evolution │   67 /100 │\n│ overall (mean) │   91 /100 │\n└────────────────┴───────────┘\n┌──────────────────────────────┬───────┬─────────────────┬──────────────────┬─────────────────┬───────────────────┬──────────────────┬────────────┐\n│                         rule │ count │            func │ usability impact │ security impact │ robustness impact │ evolution impact │ rule total │\n├──────────────────────────────┼───────┼─────────────────┼──────────────────┼─────────────────┼───────────────────┼──────────────────┼────────────┤\n│ operation-operationId-unique │     1 │  1×3÷operations │                1 │                 │                 2 │                3 │          6 │\n│       ibm-no-array-responses │     2 │ 2×10÷operations │                  │                 │                   │               20 │         20 │\n│             no-$ref-siblings │     1 │  1×1÷operations │             0.33 │                 │                   │                  │       0.33 │\n└──────────────────────────────┴───────┴─────────────────┴──────────────────┴─────────────────┴───────────────────┴──────────────────┴────────────┘\n```\n\n### JSON\nWhen displaying JSON output, the validator will produce a JSON object which complies with\n[this JSON schema](packages/validator/src/schemas/results-object.yaml). The JSON data will include information about all rule violations,\nas well as all impact score information computed from the rule violations.\nHere is an example of JSON output:\n```json\n{\n  \"error\": {\n    \"results\": [\n      {\n        \"message\": \"Path contains two or more consecutive path parameter references: /v1/clouds/{cloud_id}/{region_id}\",\n        \"path\": [\n          \"paths\",\n          \"/v1/clouds/{cloud_id}/{region_id}\"\n        ],\n        \"rule\": \"ibm-no-consecutive-path-parameter-segments\",\n        \"line\": 332\n      }\n    ],\n    \"summary\": {\n      \"total\": 1,\n      \"entries\": [\n        {\n          \"generalizedMessage\": \"Path contains two or more consecutive path parameter references\",\n          \"count\": 1,\n          \"percentage\": 100\n        }\n      ]\n    }\n  },\n  \"warning\": {\n    \"results\": [\n      {\n        \"message\": \"Operation summaries should not have a trailing period\",\n        \"path\": [\n          \"paths\",\n          \"/v1/clouds\",\n          \"post\",\n          \"summary\"\n        ],\n        \"rule\": \"ibm-summary-sentence-style\",\n        \"line\": 46\n      },\n      {\n        \"message\": \"Operation summaries should not have a trailing period\",\n        \"path\": [\n          \"paths\",\n          \"/v1/clouds\",\n          \"get\",\n          \"summary\"\n        ],\n        \"rule\": \"ibm-summary-sentence-style\",\n        \"line\": 93\n      }\n    ],\n    \"summary\": {\n      \"total\": 2,\n      \"entries\": [\n        {\n          \"generalizedMessage\": \"Operation summaries should not have a trailing period\",\n          \"count\": 2,\n          \"percentage\": 100\n        }\n      ]\n    }\n  },\n  \"info\": {\n    \"results\": [],\n    \"summary\": {\n      \"total\": 0,\n      \"entries\": []\n    }\n  },\n  \"hint\": {\n    \"results\": [],\n    \"summary\": {\n      \"total\": 0,\n      \"entries\": []\n    }\n  },\n  \"hasResults\": true\n  \"impactScore\": {\n    \"categorizedSummary\": {\n      \"usability\": 94,\n      \"security\": 100,\n      \"robustness\": 100,\n      \"evolution\": 100,\n      \"overall\": 99\n    },\n    \"scoringData\": [\n      {\n        \"rule\": \"ibm-no-consecutive-path-parameter-segments\",\n        \"count\": 1,\n        \"func\": \"1×10÷operations\",\n        \"demerits\": {\n          \"usability\": 3.33,\n          \"total\": 3.33\n        }\n      },\n      {\n        \"rule\": \"ibm-summary-sentence-style\",\n        \"count\": 2,\n        \"func\": \"2×1÷operations\",\n        \"demerits\": {\n          \"usability\": 0.67,\n          \"total\": 0.67\n        }\n      }\n    ]\n  }\n}\n```\nThe JSON output is also affected by the `-s`/`--summary-only` and `-e`/`--errors-only` options as well as the `summaryOnly` and `errorsOnly`\nconfiguration properties. It is _not_ affected by the `-q`/`--impact-score` option or `produceImpactScore` property.\n\n## Logging\nThe validator uses a *logger* for displaying messages on the console.\nThe core validator uses a single logger named `root`, while each of the rules contained in the\nIBM Cloud Validation Ruleset uses their own unique logger whose name will match the rule's id\n(e.g. `ibm-accept-header`, `ibm-schema-description-exists`, etc.).\n\nEach logger has a logging level associated with it: `error`, `warn`, `info`, and `debug`.\nEach of these levels implicitly includes the levels that precede it in the list.\nFor example, if you set the logging level of a logger to `info`, then all messages of type\n`info`, `warn`, and `error` will be displayed, but `debug` messages will not.\n\nTo set the level of the `root` logger to `info`, you could use this option: `--log-level root=info`.\n\nTo set the level of the logger used by the `ibm-accept-header` rule to `debug`,\nyou could use this option: `-l ibm-accept-header=debug`.\n\nYou can also use a glob-like value for a logger name to set the level on multiple loggers.\nFor example, to set the level for *all* loggers whose name starts with `ibm-property`, try this:\n`-l ibm-property*=debug`.\n\nEnabling debug logging for a specific rule might be useful in a situation where the rule is\nreporting violations which seem to be inexplicable. In this case, additional debug information\nmight be helpful in determining why the violations are occurring, and could possibly lead to a solution.\nFor example, suppose the `ibm-pagination-style` rule is reporting several violations,\nbut yet at first glance it's not obvious why these violations are occurring.\nTo enable debug logging for this rule, use a command like this:\n```\nlint_openapi -l ibm-pagination-style=debug my-new-api.yaml\n```\n\nThe default log level for the `root` logger is `info`, while the default log level for\nrule-specific loggers is `warn`.\n\n## Contributing\n\nSee [CONTRIBUTING](CONTRIBUTING.md).\n\n## License\n\nThis project is licensed under Apache 2.0.  Full license text is available in [LICENSE](LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FIBM%2Fopenapi-validator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FIBM%2Fopenapi-validator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FIBM%2Fopenapi-validator/lists"}