Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Last updated : Oct 26, 2022
NOT ON THE CURRENT EDITION
This blip is not on the current edition of the Radar. If it was on one of the last few editions, it is likely that it is still relevant. If the blip is older, it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the Radar. Understand more
Oct 2022
Trial ?

Spectral is a JSON/YAML linter with an emphasis on OpenAPI and AsyncAPI specifications. It ships with a comprehensive set of out-of-the-box rules for these specs that can save developers headaches when designing and implementing APIs or event-driven collaboration. These rules check for proper API parameter specifications or the existence of a license statement in the spec, among other things. The CLI makes it easy to incorporate Spectral into both local development and CI/CD pipelines, and the JavaScript API supports more advanced use cases. The GitHub site links to publicly available real-world rule sets from companies like Adidas, giving teams a head start on adopting their own linting rules.

Apr 2021
Assess ?

One of the patterns we've seen repeat itself in this publication is that static error- and style-checking tools emerge quickly after a new language gains popularity. These tools are generically known as linters — after the classic and beloved Unix utility lint, which statically analyzes C code. We like these tools because they catch errors early, before code even gets compiled. The latest instance of this pattern is Spectral, a linter for YAML and JSON. Although Spectral is a generic tool for these formats, its main target is OpenAPI (the evolution of Swagger) and AsyncAPI. Spectral ships with a comprehensive set of out-of-the-box rules for these specs that can save developers headaches when designing and implementing APIs or event-driven collaboration. These rules check for proper API parameter specifications or the existence of a license statement in the spec, among other things. While this tool is a welcome addition to the API development workflow, it does raise the question of whether a non-executable specification should be so complex as to require an error-checking technique designed for programming languages. Perhaps developers should be writing code instead of specs?

Published : Apr 13, 2021

Download the PDF

 

 

English | Español | Português | 中文

Sign up for the Technology Radar newsletter

 

Subscribe now

Visit our archive to read previous volumes