Spectral é um linter para JSON/YAML com ênfase nas especificações OpenAPI e AsyncAPI. É fornecido com um conjunto abrangente de regras prontas para usar para essas especificações, que podem evitar dores de cabeça para pessoas desenvolvedoras ao projetar e implementar APIs ou em colaboração orientada a eventos. Essas regras verificam as especificações adequadas dos parâmetros da API ou a existência de uma declaração de licença na especificação, entre outras coisas. O CLI facilita a incorporação do Spectral no desenvolvimento local e em pipelines de CI/CD, e a API JavaScript suporta casos de uso mais avançados. O site do GitHub tem links para conjuntos de regras reais disponíveis publicamente de empresas como Adidas, dando aos times uma vantagem inicial na adoção de suas próprias regras de linting.
Um padrão que vimos se repetir nesta publicação é que ferramentas estáticas de verificação de erros e estilo surgem rapidamente após uma nova linguagem ganhar popularidade. Essas ferramentas são genericamente conhecidas como linters — em homenagem ao clássico e amado utilitário do Unix, lint, que analisa estaticamente código em C. Gostamos dessas ferramentas porque elas detectam os erros cedo, antes mesmo que o código seja compilado. A instância mais recente desse padrão é Spectral, um linter para YAML e JSON. Embora Spectral seja uma ferramenta genérica para esses formatos, seus alvos principais são OpenAPI (a evolução do Swagger) e AsyncAPI. O Spectral vem com um conjunto abrangente de regras prontas para usar para especificações que podem evitar dores de cabeça para pessoas desenvolvedoras ao projetar e implementar APIs ou colaboração orientada a eventos. Essas regras verificam as especificações adequadas aos parâmetros da API ou a existência de uma declaração de licença na especificação, entre outras coisas. Embora essa ferramenta seja uma adição bem-vinda ao fluxo de desenvolvimento de APIs, ela levanta a questão: uma especificação não executável deve ser tão complexa a ponto de exigir uma técnica de verificação de erros projetada para linguagens de programação? Talvez as pessoas desenvolvedoras devam se concentrar em escrever código, e não especificações.
