discord api spec

Spesifikasi Perselisihan OpenAPI

Repositori ini berisi pratinjau publik spesifikasi OpenAPI 3.1 untuk API Discord. Saat ini, spesifikasi hanya tersedia untuk versi Discord API terbaru (v10).

️ Pratinjau publik dari spesifikasi OpenAPI dapat mengalami perubahan tanpa pemberitahuan terlebih dahulu, dan tidak boleh digunakan dalam lingkungan produksi.

Penggunaan

File Spesifikasi

Dua versi spesifikasi disertakan—spesifikasi standar dan spesifikasi pratinjau:

• openapi.json adalah spesifikasi standar yang berisi API publik yang stabil.
• openapi_preview.json adalah spesifikasi pratinjau yang berisi fitur API tidak stabil dan/atau eksperimental. Ini tidak boleh dianggap stabil atau digunakan di lingkungan produksi.

Mengintegrasikan dengan Tukang Pos

Untuk menggunakan spesifikasi dengan Postman, Anda dapat melihat koleksi publik.

Berkontribusi

Konten spesifikasi OpenAPI dibuat secara otomatis, dan oleh karena itu kami tidak mengizinkan kontribusi publik ke repo ini .

? Untuk perbaikan bug atau peningkatan, Anda dapat membuka masalah.

Konvensi spesifikasi

• Ini adalah pratinjau dan mungkin tidak benar. Jika Anda menemukan perbedaan antara spesifikasi dan dokumen kami, selain yang disebutkan di bawah, beri tahu kami, dan ikuti dokumennya, bukan spesifikasinya.
• Meskipun kita mendefinisikan gabungan anyOf dan oneOf , semuanya berarti bahwa hanya satu jenis dari daftar yang dapat digunakan sebagai format data. Misalnya anyOf: {'Cat', 'Dog'} , tetap berarti Anda dapat meneruskan Cat atau Dog , bukan Cat+Dog . Hal ini ditandai dengan ekstensi khusus x-discord-union: oneOf . Kami menggunakan anyOf ketika secara teknis kami tidak dapat menggunakan oneOf . Salah satu alasan untuk melakukan hal tersebut adalah misalnya ketika semua kolom bersifat opsional dan data yang diteruskan dapat divalidasi dengan lebih dari satu format.
• Kami menghindari penentuan bidang respons yang berlebihan dan hanya menentukan jenis bidang, seperti int32 , dan kami menghindari penentuan nilai minimum, maksimum, dll.
• Beberapa bidang yang diketik sebagai string di dokumen kami mungkin diketik sebagai int di spesifikasi. API kami menerima string untuk bidang int jika dapat diurai sebagai int. Kami pikir akan lebih tepat untuk menentukan string yang dapat diurai ini sebagai int.

Masalah yang diketahui

• (hampir) Semua bidang yang dapat dibatalkan juga ditandai sebagai opsional dan semua bidang opsional juga ditandai sebagai dapat dibatalkan.
• Operasi dan bidang tidak memiliki deskripsi.
• Operasi tidak memiliki tag.
• Bidang bendera tidak memerinci nilai bendera tertentu dan artinya.
• Argumen kueri opsional diketik sebagai nullable, meskipun itu tidak masuk akal.