Histórico da Página

OpenAPI:

Filename:

should start with uppercase letter

Todos os arquivos de especificações de API devem iniciar com letra maiúscula. Para corrigir este erro, ajuste o nome do arquivo OpenAPI, deixando-o com a primeira letra em uppercase.

should contain version (lowercase 'v')

A letra "v" no nome do arquivo OpenAPI, que indica a sua versão, deve estar escrita em minúscula. Para corrigir este erro, ajuste a letra "v" no título do arquivo de especificação da API, deixando-a em lowercase.

Content Format:

shouldn't contain weird special characteres

Esta verificação serve para garantir que não haja nenhum caracter do tipo "�", configurando um problema de enconding. Para corrigir, verifique seu arquivo OpenAPI e ajuste as ocorrências desses caracteres.

should be complient with OpenAPI in version 3.0'

A especificação de API deve conter a propriedade "openapi" (não a propriedade "swagger"). Para corrigir o erro, ajuste essa propriedade.

Servers:

should have a 'servers' property with 'URL' and 'variables'

As propriedades "url" e "variables" devem existir dentro da propriedade "servers". Para corrigir este erro, ajuste o arquivo OpenAPI de modo que exista a propriedade "servers", com suas respectivas propriedades "url" e "variables".

should have an URL consistent with our model

As URLs descritas dentro da propriedade "url" (dentro de "servers") devem cumprir as regras da seguinte expressão regular: /(?:.*)\/api\/(?:.*)\/v[0-9]*$/ . Um erro comum é a adição desnecessária de uma barra ("/") ao final da URL. Corrija a URL do servidor para que o erro pare de ser apontado.

Version:

should contain the same version on 'info' as in filename

O nome do arquivo OpenAPI deve trazer a mesma versão contida na "info" deste mesmo arquivo. Para corrigir esse erro, faça o ajuste da versão, garantindo a consistência entre o nome do arquivo e as informações contidas na "info".

Endpoints:

shouldn't contain 'post', 'put', 'get' or 'delete' in the URL

Nenhum endpoint pode conter, em sua url (path), métodos HTTP. O path do endpoint deve especificar apenas o caminho que o usuário enviará a requisição.

should contain success responses for all http verbs

Para cada endpoint e método HTTP, deve existir uma response para caso de sucesso (200) na requisição.

should specify 'Id' for all PUT operations

Nenhum endpoint de collection pode aceitar métodos PUT. Todas as operações de método PUT devem ter especificadas um {id}.

should have unique 'operationId'

As propriedades "operationId" de cada um dos endpoints tem que ser únicas. Não podem existir dois endpoints com a mesma operationId.

Schemas:

shouldn't contain 'schemas' definition inside this file

Dentro da especificação OpenAPI não pode conter definição de schemas. Os schemas devem ser declarados em outro arquivo, como especificado na documentaçãono Guia de Implementação de Integrações.

should use external schemas for all requests and responses

Todas as requests e responses de todos os endpoints devem utilizar schemas externos, sendo apenas referenciados dentro do OpenAPI.

should be dereferenced. This means all external references are correct (FilePaths and Object property names)

Todos os schemas referenciados no arquivo Open API devem conseguir ser derreferenciados. O algoritmo de derreferenciação acessa cada uma das referências à schemas e injeta todo o conteúdo do jsonSchema externo no objeto parseado do OpenAPI. Logo, um schema que não pôde ser derreferenciado é um schema que não conseguiu ser acessado da forma correta.

should contain the same Id property name in URL and body

o O type {id} descrito no path do endpoint deve estar presente também no schemajsonSchema referenciado.

should contain 'hasNext' prop if there is 'items' prop and vice versa

Caso um determinado type no jsonSchema tenha a propriedade "hasNext", obrigatoriamente este deve possuir também a propriedade "items", e vice-versa. Isso ocorre pois a propriedade "hasNext" serve para indicar que se trata de um type paginado, enquanto a propriedade "items" evidencia quais são os types a serem paginados.

should be 'required=true' at schema, because it's a final path param

Sempre que o path terminar com um {id}, este {id} deve obrigatoriamente ser required em seu schema (por ser um dado obrigatório).

should have 'hasNext' when it's an 'getAll' endpoint

É chamado de "getAll" todo path que, quando requisitado por método get, retorna uma collection. Logo, não faz sentido um endpoint de retorno de coleção não retornar uma paginação de elementos (caracterizada pela presença do hasNext).

shouldn't have 'hasNext' when it's an 'getOne' endpoint

É chamado de "getOne" todo path que, quando requisitado por método get, retorna um elemento específico ({id}). Logo, não faz sentido um endpoint de retorno único retornar uma paginação de elementos (caracterizada pela presença do hasNext).

Parameters:

should have 'page', 'pagesize' and 'order' for collection endpoints

Todos os endpoints de collection devem possuir meios para controlar a paginação. Logo, devem estar presentes os parâmetros "page" para indicar a página corrente, "pagesize" para identificar o tamanho da página e "order" para tratar a ordenação.

should use common parameters

A API deve referenciar parâmetros padronizados para Authorization, Order, Page, PageSize, AcceptLanguage, Fields e Expand. Esses parâmetros devem ser referenciados diretamente do nosso repositório no GitHub, através do arquivo totvsApiTypesBase.json. Maiores informações podem ser encontradas no nosso Guia de Implementação de Integrações.

should reference valid param objects

Todos os objetos referenciado nos "parameters" devem ser válidos. Esse erro é disparado quando um objeto em um parâmetro não consegue ser acessado de forma apropriada (geralmente por erro de digitação, causando inconsistência entre a url que faz a referência e o nome do objeto em si).

should contain path param defined 'params' property

should be 'required=true' when final path param

Sempre que o path terminar com um {id}, o parâmetro referente a aquele {id} deve obrigatoriamente ser required (por ser um dado obrigatório).

Errors:

should use common errors schema

O OpenAPI deve utilizar responses padronizadas para casos de erros (ErrorModel, ErrorModelBase e ErrorDetail). Maiores informações podem ser encontradas no nosso Guia de Implementação de Integrações.

xtotvs:

paths:

should contain xtotvs/productinformation as an array inside 'paths'

should contain 'product' as a key in productInformation, inside 'paths'

should contain 'available' inside productInformation, inside 'paths'

all products declared inside info should also exist inside paths' x-totvs

all 'available' properties must be boolean

info:

should have 'product' in the correct pattern

segment name should be standardized

product name should be standardized

all products declared inside paths should also exist inside info x-totvs

Schemas:

Filename:

should start with uppercase letter

should contain version separtor (_)

shouldn't contain v (_v)

Schemas:

should reference valid objects

xtotvs:

should be an object in 'info' and may have a 'productInformation' porperty as an array

should have available as a boolean type inside x-totvs

should be available=true in x-totvs, because it is required

should be an array in properties inside 'definitions'

should have the property 'product' correctly spelled

should have the property 'available' correctly spelled

should have required as a boolean type inside x-totvs

should have canUpdate as a boolean type inside x-totvs

Enum:

should be a string

Required:

should have the 'required' field as an array

should have every 'required' element as strings

should have every element of the 'required' array as a property