discord api spec

Especificação Discord OpenAPI

Este repositório contém a visualização pública da especificação OpenAPI 3.1 para API do Discord. Atualmente, a especificação está disponível apenas para a versão mais recente da API Discord (v10).

️ A visualização pública da especificação OpenAPI está sujeita a alterações significativas sem aviso prévio e não deve ser usada em ambientes de produção.

Uso

Arquivos de especificações

Duas versões da especificação estão incluídas – a especificação padrão e a especificação de visualização:

• openapi.json é a especificação padrão que contém a API pública estável.
• openapi_preview.json é a especificação de visualização que contém recursos de API instáveis ​​e/ou experimentais. Isto não deve ser considerado estável ou usado em ambientes de produção.

Integrando com o Postman

Para usar as especificações com o Postman, você pode visualizar a coleção pública.

Contribuindo

O conteúdo das especificações OpenAPI é gerado automaticamente e, portanto, não permitimos contribuições públicas para este repositório .

? Para correções de bugs ou melhorias, você pode abrir um problema.

Convenções de especificações

• Esta é uma prévia e pode não estar correta. Se você encontrar discrepâncias entre as especificações e nossos documentos, além dos mencionados abaixo, informe-nos e siga os documentos, não as especificações.
• Embora definamos uniões anyOf e oneOf , todas elas significam que apenas um tipo da lista pode ser usado como formato de dados. Por exemplo, anyOf: {'Cat', 'Dog'} , ainda significa que você pode passar Cat ou Dog , não Cat+Dog . Isso é representado pela extensão personalizada x-discord-union: oneOf . Usamos anyOf quando tecnicamente não podemos usar oneOf . Uma das razões para fazer isso é, por exemplo, quando todos os campos são opcionais e os dados transmitidos podem ser validados com mais de um formato.
• Evitamos especificar demais os campos de resposta e apenas definimos tipos de campo, como int32 , e evitamos definir mínimos, máximos específicos, etc.
• Alguns campos digitados como strings em nossos documentos podem ser digitados como ints nas especificações. Nossa API aceita strings para campos int se eles puderem ser analisados ​​como ints. Achamos que será mais preciso especificar essas strings analisáveis ​​como ints.

Problemas conhecidos

• (quase) Todos os campos anuláveis ​​são adicionalmente marcados como opcionais e todos os campos opcionais são adicionalmente marcados como anuláveis.
• Operações e campos não possuem descrições.
• As operações não possuem tags.
• Os campos de sinalização não detalham valores de sinalização específicos e seu significado.
• Argumentos de consulta opcionais são digitados como anuláveis, mesmo que não faça muito sentido.