discord api spec

Spécification OpenAPI de Discord

Ce référentiel contient l'aperçu public de la spécification OpenAPI 3.1 pour l'API Discord. Actuellement, la spécification n'est disponible que pour la version la plus récente de l'API Discord (v10).

️ La préversion publique de la spécification OpenAPI est sujette à des modifications importantes sans préavis et ne doit pas être utilisée dans des environnements de production.

Usage

Fichiers de spécifications

Deux versions de la spécification sont incluses : la spécification standard et la spécification d'aperçu :

• openapi.json est la spécification standard qui contient l'API publique stable.
• openapi_preview.json est la spécification d'aperçu qui contient des fonctionnalités d'API instables et/ou expérimentales. Cela ne doit pas être considéré comme stable ou utilisé dans des environnements de production.

Intégration avec Postman

Pour utiliser la spécification avec Postman, vous pouvez afficher la collection publique.

Contribuer

Le contenu des spécifications OpenAPI est généré automatiquement et nous n'autorisons donc pas les contributions publiques à ce référentiel .

? Pour des corrections de bugs ou des améliorations, vous pouvez ouvrir un problème.

Conventions de spécifications

• Ceci est un aperçu et il se peut qu'il ne soit pas correct. Si vous constatez des divergences entre les spécifications et nos documents, autres que celles mentionnées ci-dessous, faites-le-nous savoir et suivez les documents, pas les spécifications.
• Même si nous définissons les unions anyOf et oneOf , elles signifient toutes qu'un seul type de la liste peut être utilisé comme format de données. Par exemple, anyOf: {'Cat', 'Dog'} , signifie toujours que vous pouvez transmettre Cat ou Dog , pas Cat+Dog . Ceci est signifié par l'extension personnalisée x-discord-union: oneOf . Nous utilisons anyOf lorsque nous ne pouvons techniquement pas utiliser oneOf . L'une des raisons de procéder ainsi est, par exemple, lorsque tous les champs sont facultatifs et que les données transmises peuvent être validées avec plus d'un format.
• Nous évitons de trop spécifier les champs de réponse et définissons simplement des types de champs, comme int32 , et nous évitons de définir des minimums, des maximums, etc.
• Certains champs saisis sous forme de chaînes dans nos documents peuvent être saisis sous forme d'entiers dans la spécification. Notre API accepte les chaînes pour les champs int si elles sont analysables en tant qu'ints. Nous pensons qu'il sera plus précis de spécifier ces chaînes analysables en entier comme des entiers.

Problèmes connus

• (presque) Tous les champs nullables sont en outre marqués comme facultatifs et tous les champs facultatifs sont en outre marqués comme nullables.
• Les opérations et les champs n'ont pas de description.
• Les opérations n'ont pas de balises.
• Les champs d'indicateur ne détaillent pas les valeurs d'indicateur spécifiques ni leur signification.
• Les arguments de requête facultatifs sont saisis comme nullables, même si cela n'a pas beaucoup de sens.