Доменное API - Список команд API

Dynadot API

Начало работы с нашим RESTful API

API Dynadot разработан для бесшовной интеграции с вашими системами. Наш API предлагает предсказуемые URL-адреса, ориентированные на ресурсы, поддерживает запросы с телами, закодированными в формате JSON, возвращает ответы в формате JSON и XML, а также соответствует стандартным методам HTTP, аутентификации и кодам ответов.Вы можете использовать API Dynadot как в тестовом, так и в рабочем режимах. Режим определяется по API-ключу, который используется для аутентификации ваших запросов. Тестовый режим позволяет вам симулировать и проверять вашу интеграцию API, не влияя на реальные данные или транзакции.API Dynadot в первую очередь ориентирован на управление доменами, обработку заказов и сопутствующие услуги. Вы можете выполнять такие действия, как регистрация, передача и продление доменов, управление настройками DNS, а также просмотр или обновление заказов в аккаунте.Обратите внимание: Массовое создание, обновление и удаление не поддерживаются, и каждый из этих типов запросов ограничен одним объектом или действием.

Генерация ваших API-ключейПрежде чем начать делать какие-либо запросы к API, необходимо сгенерировать ваш API Key и API Secret.Эти ключи необходимы для аутентификации и обеспечения безопасности ваших действий при взаимодействии с нашим API.Вы можете сгенерировать как API Key, так и API Secret в разделе API в настройках вашего аккаунта.1. Войдите в свой аккаунт на Dynadot.2. Перейдите в Инструменты > API.Сгенерируйте свой API Key и API Secret на этой странице.

Присоединяйтесь к нашему сообществуЕсть идеи или предложения? Поговорите напрямую с нашими профессиональными инженерами.Discord

HTTP МетодAPI использует стандартные методы HTTP для выполнения операций с ресурсами:

Method	Description
GET	GET Request: Retrieve detailed information about a specified resource
POST	POST Request: Create a new resource
PUT	PUT Request: Fully update the specified resource
DELETE	DELETE Request: Remove the specified resource

URL

Базовый URL для всех API-запросов:https://api.dynadot.com/

Формат полного URL:http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action

https://api.dynadot.com/restful/v1/domains/{domain_name}/search

Sure! Please provide the text you would like me to translate into Russian.

Текущая версия API составляетv

При формировании URL-адреса API-запроса необходимо указывать только основную версию. Небольшие и патч-обновления разработаны с учетом обратной совместимости и не будут вносить изменения, которые могут нарушить работу вашего существующего кода. Это обеспечивает стабильность, позволяя вам получать преимущества от постепенных улучшений и исправлений без необходимости модификации вашей реализации.При выпуске будущих версий мы будем поддерживать обратную совместимость со старыми версиями в течение определенного времени. Новые функции и значительные изменения будут вводиться в рамках основных версий.

HeaderЗаголовок API-запроса содержит метаданные о запросе. Эти метаданные предоставляют важный контекст для правильной обработки запроса сервером. Обычно используемые заголовки включают:

Content-TypeУказывает формат данных, отправляемых в теле запроса. Сервер использует эту информацию для правильного разбора запроса. В настоящее время единственным допустимым значением является: application/json

Content-Type: application/json

ПринятьИнформирует сервер о формате ответа, ожидаемом клиентом.Возможные значения: application/json, application/xml

Accept: application/json

АвторизацияВсе запросы к API должны включать API-ключ для аутентификации. Вы можете получить свой API-ключ на панели управления вашего аккаунта.You can generate an API key in API setting page

Authorization: Bearer YOUR_API_KEY

X-Request-IDЗаголовок X-Request-ID является необязательным заголовком, который используется для уникальной идентификации каждого запроса к API. При его включении этот заголовок помогает отслеживать и сопоставлять запросы между системами и журналами, что упрощает отладку и мониторинг активности API.Значение X-Request-ID должно быть действительным UUID (Универсальный Уникальный Идентификатор), соответствующим стандартному формату: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (например, 123e4567-e89b-12d3-a456-426614174000).

X-Request-ID: 550e8400-e29b-41d4-a716-446655440000

X-ПодписьЗаголовок X-Signature является обязательным механизмом безопасности для транзакционных запросов, включая те, которые извлекают конфиденциальную информацию или обновляют данные. Он обеспечивает подлинность, целостность и невозможность отказа от API-запросов, требуя от клиентов подписывать полезную нагрузку запроса с использованием HMAC-SHA256.

Чтобы сгенерировать подпись, вам понадобятся следующие значенияAPI-ключ: Ваш уникальный API-ключ.2. Полный путь и запрос: Полный путь к конечной точке API вместе с параметрами запроса.3. X-Request-Id: Идентификатор запроса. Если он недоступен, вы можете ввести пустую строку.4. Тело запроса: Тело запроса. Если оно пустое или равно null, вы можете ввести пустую строку.

Строка для подписи представляет собой комбинацию указанных выше значений, соединённых в следующем порядке:

apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)

apiKey = "your_api_key"
fullPathAndQuery = "/v1/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"


stringToSign = "your_api_key\n/v1/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"

Сгенерируйте подпись HMAC-SHA256После формирования строки для подписи вам необходимо применить HMAC-SHA256 шифрование с использованием вашего секретного ключа. Этот процесс создаст подпись.Подпись создается с использованием следующих шагов:1. Используйте алгоритм HMAC-SHA256.Sure! Please provide the text you would like me to translate into Russian.Используйте секрет в качестве ключа.
Примените сгенерированную подпись в качестве значения X-Signature в заголовке запроса.

X-Signature: {HMAC-SHA256 Signature}

BodyТело API-запроса используется для отправки данных на сервер. Обычно оно включается в запросы POST, PUT или PATCH (не обычно для запросов GET или DELETE).

Sure! Please provide the text you would like me to translate into Russian.Формат данных тела определяется заголовком Content-Type. Некоторые распространенные форматы включают:

{
    "domainName": "domain.com",
    "showPrice": "yes",
    "currency": "USD"
}

Типичные случаи использованияPOST Запросы: Метод POST используется для создания нового ресурса на сервере. Тело запроса обычно содержит детали ресурса.PUT Запросы: Метод PUT используется для обновления существующего ресурса путем его полного замещения. Тело запроса содержит полностью обновленный ресурс.GET-запросы: Метод DELETE используется для удаления существующего ресурса с сервера. У него нет тела запроса.DELETE Запросы: Метод GET используется для получения существующего ресурса с сервера. У него нет тела запроса

Response FormatВсе ответы API возвращаются в формате JSON или XML, при этом формат данных тела определяется заголовком Accept, предоставляя запрашиваемые данные или сообщение об ошибке, если это необходимо.

Sure! Please provide the text you would like me to translate into Russian.Sure! Please provide the text you would like me to translate into Russian.

Код: Статус запросаСообщение: Более подробное описание статусаДанные: Тело ответа

{
    "Code": "200",
    "Message": "Success",
    "Data": {}
}

Обработка ошибокКоды состояния HTTP — это стандартизированные трехзначные числа, которые сервер возвращает, чтобы указать результат запроса клиента. Они предоставляют важную информацию о том, был ли запрос успешно обработан, требует ли он дальнейших действий или возникла ошибка. Эти коды делятся на пять категорий, каждая из которых представляет собой отдельный тип ответа.Коды состояния нашего API соответствуют протоколу HTTP/1.1, широко принятому стандарту, который обеспечивает последовательное и надежное взаимодействие. Используя HTTP/1.1, мы используем такие функции, как постоянные соединения и улучшенное кэширование, чтобы оптимизировать взаимодействие между клиентом и сервером.

2xx (Успешно): Указывает на то, что команда была получена и принята.

200Код состояния указывает на то, что запрос выполнен успешно.

201Код состояния указывает на то, что запрос был выполнен, и в результате было создано одно или несколько новых ресурсов.

202Код состояния указывает на то, что запрос принят для обработки, но обработка еще не завершена.

249Пользователь отправил слишком много запросов за короткий промежуток времени.

4xx (Ошибка клиента): Указывает на то, что клиент допустил ошибку в запросе, например, предоставив недопустимый ввод или не имея надлежащей авторизации.

400Код состояния указывает на то, что сервер не может или не будет обрабатывать запрос из-за того, что воспринимается как ошибка клиента.

401Код состояния указывает на то, что запрос не был выполнен, так как отсутствуют действительные учетные данные для аутентификации целевого ресурса.

402Код статуса указывает на то, что запрос не был выполнен из-за проблемы с оплатой.

403Код состояния указывает на то, что сервер понял запрос, но отказывается его выполнить.

404Код состояния указывает на то, что исходный сервер не нашел актуальное представление для целевого ресурса или не желает раскрывать, что такое представление существует.

409Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.

5xx (Ошибка сервера): Указывает на то, что сервер столкнулся с ошибкой или не может выполнить запрос.

500Код состояния указывает на то, что сервер столкнулся с неожиданным условием, которое помешало ему выполнить запрос.

501Код состояния указывает на то, что сервер не поддерживает функциональность, необходимую для выполнения запроса.

502Код состояния указывает на то, что сервер, действуя в качестве шлюза или прокси, получил недействительный ответ от входящего сервера, к которому он обращался при попытке выполнить запрос.

503Код состояния указывает на то, что сервер в данный момент не может обработать запрос из-за временной перегрузки или запланированного обслуживания, которое, вероятно, будет устранено после некоторой задержки.

504Код состояния указывает на то, что сервер, действуя как шлюз или прокси, не получил своевременный ответ от вышестоящего сервера, к которому ему нужно было получить доступ для завершения запроса.

КодСтатус Название

200Успех

201Создано

202Принято

249Слишком много запросов

400Неверный запрос

401Неавторизованный

402Требуется оплата

403Запрещено

404Не найдено

409Конфликт

500Внутренняя ошибка сервера

501Не реализовано

502Плохой шлюз

503Сервис недоступен

504Таймаут шлюза

Ограничение скоростиЗапросы должны отправляться по https (защищенный сокет) для обеспечения безопасности. Только 1 запрос может обрабатываться одновременно, поэтому, пожалуйста, дождитесь завершения вашего текущего запроса, прежде чем отправлять другой.

Вы получите разные количества нитей в зависимости от уровня цен вашего аккаунта:

Price level	Account
Regular	1 thread
Bulk	5 threads
Super Bulk	25 threads

<Response>
  <status>
    <code>429</code>
    <message>Too Many Requests</message>
  </status>
  <error>
    <description>You have reached the maximum allowed requests within the concurrent limit of your account. Please try again later.</description>
  </error>
</Response>

{
  "code": 429,
  "message": "Too Many Requests",
  "error": {
    "description": "You have reached the maximum allowed requests within the concurrent limit of your account. Please try again later."
  }
}

Обзор журнала изменений

Журнал изменений — это подробная запись изменений, улучшений, исправлений ошибок и новых функций, введенных в каждой версии API. Он обеспечивает прозрачность для пользователей и разработчиков, документируя влияние каждого обновления. Журнал состоит из двух ключевых частей:

Версия APIЭта часть подчеркивает систему версионирования API, которая помогает разработчикам отслеживать эволюцию функций и обеспечивать совместимость. Каждая версия API идентифицируется уникальным номером версии (например, v1.0.1, v2.2.3) и представляет собой значимую веху или релиз. Версионирование позволяет пользователям поддерживать интеграции с минимальными перебоями, выбирая обновления, когда они готовы.

История измененийИстория изменений предоставляет подробную информацию об обновлениях, исправлениях ошибок, устареваниях и улучшениях, введенных в каждой версии. Она описывает конкретные изменения, внесенные в конечные точки, параметры, механизмы аутентификации или форматы ответов. Этот раздел обеспечивает полную прозрачность для разработчиков относительно того, что изменилось, и позволяет им соответственно корректировать свои реализации. Поддерживая четкий и детализированный журнал изменений, мы стремимся предоставить разработчикам инструменты и информацию, необходимые для эффективного и уверенного управления интеграциями.

Версия API

Наше API в настоящее время находится на версииv

Коды версий используются для систематической идентификации и управления обновлениями API. Они следуют формату семантического версионирования (SemVer):

Sure! Please provide the text you would like me to translate into Russian.Sure! Please provide the text you would like me to translate into Russian.Sure! Please provide the text you would like me to translate into Russian.

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

Основная версияОпределение: Представляет собой значительные изменения, которые могут нарушить обратную совместимость.Of course! Please provide the text you would like me to translate into Russian.<Major>.x.x

Примеры:v1.0.0->v2.0.0Полный редизайн API или несовместимые изменения схемы.

Небольшая версияОпределение: Указывает на добавление функций, совместимых с предыдущими версиями.Of course! Please provide the text you would like me to translate into Russian.x.<Minor>.x

Примеры:v1.0.0->v1.1.0Добавление новых конечных точек или методов при сохранении обратной совместимости.

Версия патчаОпределение: Относится к обратнос совместимым исправлениям ошибок или незначительным улучшениям.Of course! Please provide the text you would like me to translate into Russian.x.x.<Patch>

Примеры:v1.0.0->v1.1.0Исправление незначительной ошибки в конечной точке API.

Журнал изменений API

Журнал изменений — это подробная запись изменений, улучшений, исправлений ошибок и новых функций, введенных в каждой версии программного обеспечения или API. Он обеспечивает прозрачность для пользователей и разработчиков, документируя влияние каждого обновления.

Типичная запись в журнале изменений включает:Описание: Краткое объяснение того, что было изменено.Затронутые компоненты: Конкретные модули, конечные точки или функции, на которые повлиял данный изменения.

Пример: Добавлена поддержка этой новой команды API<Регистрация домена>

История измененийСледите за всеми изменениями в API Dynadot.