discord api spec

Discord OpenAPI-Spezifikation

Dieses Repository enthält die öffentliche Vorschau der OpenAPI 3.1-Spezifikation für die Discord-API. Derzeit ist die Spezifikation nur für die neueste Discord-API-Version (v10) verfügbar.

️ Die öffentliche Vorschau der OpenAPI-Spezifikation unterliegt wichtigen Änderungen ohne Vorankündigung und sollte nicht in Produktionsumgebungen verwendet werden.

Verwendung

Spezifikationsdateien

Es sind zwei Versionen der Spezifikation enthalten – die Standardspezifikation und die Vorschauspezifikation:

• openapi.json ist die Standardspezifikation, die die stabile, öffentliche API enthält.
• openapi_preview.json ist die Vorschauspezifikation, die instabile und/oder experimentelle API-Funktionen enthält. Dies sollte nicht als stabil betrachtet oder in Produktionsumgebungen verwendet werden.

Integration mit Postman

Um die Spezifikation mit Postman zu verwenden, können Sie die öffentliche Sammlung anzeigen.

Mitwirken

OpenAPI-Spezifikationsinhalte werden automatisch generiert und daher gestatten wir keine öffentlichen Beiträge zu diesem Repo .

? Für Fehlerbehebungen oder Verbesserungen können Sie ein Problem eröffnen.

Spezifikationskonventionen

• Dies ist eine Vorschau und möglicherweise nicht korrekt. Wenn Sie Abweichungen zwischen der Spezifikation und unseren Dokumenten feststellen, die nicht die unten aufgeführten sind, teilen Sie uns dies mit und befolgen Sie die Dokumente, nicht die Spezifikation.
• Obwohl wir die Gewerkschaften anyOf und oneOf definieren, bedeuten sie alle, dass nur ein Typ aus der Liste als Datenformat verwendet werden kann. Beispielsweise bedeutet anyOf: {'Cat', 'Dog'} immer noch, dass Sie entweder Cat oder Dog übergeben können, nicht Cat+Dog . Dies wird durch die benutzerdefinierte Erweiterung x-discord-union: oneOf angezeigt. Wir verwenden anyOf , wenn wir oneOf technisch nicht verwenden können. Einer der Gründe hierfür liegt beispielsweise darin, dass alle Felder optional sind und die übergebenen Daten in mehr als einem Format validiert werden könnten.
• Wir vermeiden es, Antwortfelder zu spezifizieren und lediglich Feldtypen wie int32 zu definieren, und wir vermeiden die Definition spezifischer Mindest- und Höchstwerte usw.
• Einige Felder, die in unseren Dokumenten als Zeichenfolgen eingegeben wurden, können in der Spezifikation als Ganzzahlen eingegeben werden. Unsere API akzeptiert Zeichenfolgen für Int-Felder, wenn diese als Ints analysiert werden können. Wir denken, dass es präziser wäre, diese int-analysierbaren Strings als Ints anzugeben.

Bekannte Probleme

• (Fast) Alle nullable-Felder sind zusätzlich als optional markiert und alle optionalen Felder sind zusätzlich als nullable markiert.
• Vorgänge und Felder haben keine Beschreibungen.
• Vorgänge haben keine Tags.
• Flag-Felder enthalten keine Einzelheiten zu spezifischen Flag-Werten und deren Bedeutung.
• Optionale Abfrageargumente werden als NULL-Werte eingegeben, auch wenn dies wenig Sinn ergibt.