discord api spec

Especificación de Discord OpenAPI

Este repositorio contiene la vista previa pública de la especificación OpenAPI 3.1 para la API de Discord. Actualmente, la especificación solo está disponible para la versión más reciente de Discord API (v10).

️ La vista previa pública de la especificación OpenAPI está sujeta a cambios importantes sin previo aviso y no debe usarse en entornos de producción.

Uso

Archivos de especificaciones

Se incluyen dos versiones de la especificación: la especificación estándar y la especificación de vista previa:

• openapi.json es la especificación estándar que contiene la API pública estable.
• openapi_preview.json es la especificación de vista previa que contiene características de API inestables y/o experimentales. Esto no debe considerarse estable ni utilizarse en entornos de producción.

Integración con cartero

Para utilizar la especificación con Postman, puede ver la colección pública.

Contribuyendo

El contenido de las especificaciones de OpenAPI se genera automáticamente y, por lo tanto , no permitimos contribuciones públicas a este repositorio .

? Para corregir errores o mejorar, puede abrir un problema.

Convenciones de especificaciones

• Esta es una vista previa y puede que no sea correcta. Si encuentra discrepancias entre las especificaciones y nuestros documentos, distintas de las que se mencionan a continuación, infórmenos y siga los documentos, no las especificaciones.
• Aunque definimos las uniones anyOf y oneOf , todas significan que solo se puede utilizar un tipo de la lista como formato de datos. Por ejemplo, anyOf: {'Cat', 'Dog'} , todavía significa que puedes pasar Cat o Dog , no Cat+Dog . Esto se indica mediante la extensión personalizada x-discord-union: oneOf . Usamos anyOf cuando técnicamente no podemos usar oneOf . Una de las razones para hacerlo es, por ejemplo, cuando todos los campos son opcionales y los datos pasados ​​se pueden validar con más de un formato.
• Evitamos especificar demasiado los campos de respuesta y simplemente definimos tipos de campos, como int32 , y evitamos definir mínimos, máximos, etc.
• Algunos campos escritos como cadenas en nuestros documentos pueden escribirse como ints en la especificación. Nuestra API acepta cadenas para campos int si se pueden analizar como ints. Creemos que será más preciso especificar estas cadenas analizables int como ints.

Problemas conocidos

• (casi) Todos los campos que aceptan nulos se marcan adicionalmente como opcionales y todos los campos opcionales se marcan adicionalmente como que aceptan nulos.
• Las operaciones y los campos no tienen descripciones.
• Las operaciones no tienen etiquetas.
• Los campos de bandera no detallan valores de bandera específicos y su significado.
• Los argumentos de consulta opcionales se escriben como anulables, aunque no tiene mucho sentido.