discord api spec

Спецификация Discord OpenAPI

Этот репозиторий содержит общедоступную предварительную версию спецификации OpenAPI 3.1 для API Discord. В настоящее время спецификация доступна только для самой последней версии Discord API (v10).

️ В общедоступную предварительную версию спецификации OpenAPI могут быть внесены критические изменения без предварительного уведомления, и ее не следует использовать в производственных средах.

Использование

Файлы спецификаций

Включены две версии спецификации — стандартная и предварительная:

• openapi.json — это стандартная спецификация, содержащая стабильный общедоступный API.
• openapi_preview.json — это предварительная версия, содержащая нестабильные и/или экспериментальные функции API. Это не следует считать стабильным или использовать в производственных средах.

Интеграция с Почтальоном

Чтобы использовать спецификацию с Postman, вы можете просмотреть общедоступную коллекцию.

Содействие

Содержимое спецификации OpenAPI генерируется автоматически, поэтому мы не разрешаем публичный доступ к этому репозиторию .

? Для исправления ошибок или улучшений вы можете открыть проблему.

Соглашения о спецификациях

• Это предварительный просмотр и он может быть неправильным. Если вы обнаружите расхождения между спецификацией и нашей документацией, кроме упомянутых ниже, сообщите нам об этом и следуйте документации, а не спецификации.
• Несмотря на то, что мы определяем объединения anyOf и oneOf , все они означают, что в качестве формата данных можно использовать только один тип из списка. Например, anyOf: {'Cat', 'Dog'} по-прежнему означает, что вы можете передать либо Cat , либо Dog , а не Cat+Dog . Это обозначается специальным расширением x-discord-union: oneOf . Мы используем anyOf , когда технически не можем использовать oneOf . Одна из причин сделать это, например, когда все поля являются необязательными и переданные данные могут быть проверены более чем в одном формате.
• Мы избегаем чрезмерного указания полей ответа и просто определяем типы полей, например int32 , а также избегаем определения конкретных минимумов, максимумов и т. д.
• Некоторые поля, введенные в нашей документации как строки, в спецификации могут быть введены как целые числа. Наш API принимает строки для полей типа int, если их можно анализировать как целые числа. Мы думаем, что будет точнее указать эти строки, поддающиеся int-анализу, как целые числа.

Известные проблемы

• (почти) Все поля, допускающие значение NULL, дополнительно помечаются как необязательные, а все необязательные поля дополнительно помечаются как допускающие значение NULL.
• Операции и поля не имеют описания.
• Операции не имеют тегов.
• Поля флагов не детализируют конкретные значения флагов и их значение.
• Необязательные аргументы запроса вводятся как допускающие значение NULL, хотя это не имеет особого смысла.