使用RESTfulAPI有效率地管理Dynadot域名,Webhook功能上线

关于Dynadot

Dynadot是通过ICANN认证的域名注册商,自2002年成立以来,服务于全球108个国家和地区的客户,为数以万计的客户提供简洁,优惠,安全的域名注册以及管理服务。

Dynadot平台操作教程索引(包括域名邮箱,解析,建站,优惠长期更新)

关于RESTful API

API,即应用程序接口的简称。一般来说,API是用于软件或应用程序来使用的代码,API可以是一组数量上千、极其复杂的函数和副程序,可以实现很多操作。许多系统应用程序借由API接口来实现。

如果要找自己的访问密钥,则需要登陆到后台,在左侧的菜单栏中选择工具>用户接口(API)这一项。输入个人的密码,并选择生成新密钥此项。

Dynadot API 旨在与您的系统无缝集成。我们的 API 具有可预测的面向资源的 URL,支持 JSON 编码的请求体,返回 JSON 编码和 XML 编码的响应,并遵循标准的 HTTP 方法、认证和响应代码。

您可以在测试模式和实时模式下使用Dynadot API。所使用的模式由用于认证您请求的API密钥决定。测试模式允许您模拟并验证您的API集成,而不影响实时数据或交易。

Dynadot API 主要专注于域名管理、订单处理和相关服务。您可以执行注册、转移和续订域名、管理 DNS 设置以及查看或更新账户订单等操作。

请注意:不支持批量创建、更新、删除操作,每种请求类型限制为一个对象或操作。

Webhook 概述

Webhooks 是自动化流程和集成系统的得力工具,让您能够实时接收账户或域名设置中事件或变更的通知。通过配置 webhooks,您可以在外部系统中触发操作、更新数据库或根据特定事件发送通知。

Dynadot API支持针对各种事件的Webhook通知,例如域名注册、转移、续费和到期,以便您能采取相应行动。

要使用Webhook,您需要提供一个URL端点,通知将发送至此。您可以在账户设置中配置您的Webhook URL、密钥和秘密。当事件发生时,Dynadot会向指定URL发送一个POST请求,附带相关数据。

Webhook 请求头

Webhook请求的头部包含关于请求的元数据。这些元数据为服务器正确处理请求提供了关键上下文。常用头部包括:

Content-Type

指定请求体中发送数据的格式。服务器使用此信息来正确解析请求。目前唯一接受的值是:application/json。

复制代码
Example :

Content-Type: application/json

授权

所有Webhook请求都将包含一个用于身份验证的Webhook密钥。您可以从账户仪表板获取您的Webhook密钥。

复制代码
Example:

Authorization: Bearer WEBHOOK_KEY

X-签名

X-Signature 头是事务性请求的强制性安全机制,包括那些检索敏感信息或更新数据的请求。它通过要求客户端使用 HMAC-SHA256 对请求负载进行签名,确保 Webhook 请求的真实性、完整性和不可否认性。

要生成签名,您需要以下值

  1. WEBHOOK密钥 : 您的唯一WEBHOOK密钥。

  2. 完整路径和查询 :WEBHOOK 端点的完整路径以及查询参数。

  3. X-Request-Id :请求 ID。如果不可用,您可以输入空字符串。

  4. 请求正文 :请求的正文部分。如果此部分为空或为 null,您可以输入空字符串。

待签名的字符串是上述值的组合,按以下顺序连接:

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

复制代码
Example

webhookKey = "your_webhook_key"

fullPathAndQuery = "/v2/some/endpoint?param=value"

xRequestId = "unique-request-id"

requestBody = "{\"key\":\"value\"}"
stringToSign = "your_webhook_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"

生成 HMAC-SHA256 签名

构建stringToSign后,使用HMAC-SHA256 算法,以您的密钥 为钥匙计算签名,然后Base64编码 结果。签名的生成遵循以下步骤:

  1. 使用 HMAC-SHA256 算法。

  2. 将stringToSign(UTF-8编码)作为输入消息。

  3. 使用您的密钥(UTF-8编码)作为钥匙。4. 将HMAC输出进行Base64编码(标准Base64)

将生成的签名 用作请求头中X-Signature 的值。

复制代码
Example :

X-Signature: {HMAC-SHA256 Signature}

示例代码:

     

import base64

import hashlib

import hmac

import uuid



def create_signature(webhook_key, webhook_secret, full_path_and_query, x_request_id, request_body=""):

    string_to_sign = (

        webhook_key + "\n" +

        full_path_and_query + "\n" +

        (x_request_id or "") + "\n" +

        (request_body or "")

    )



    digest = hmac.new(

        webhook_secret.encode("utf-8"),

        string_to_sign.encode("utf-8"),

        hashlib.sha256

    ).digest()



    return base64.b64encode(digest).decode("utf-8")





webhook_key = "your_webhook_key"

webhook_secret = "your_secret"

full_path_and_query = "/v2/some/webhook/path"

x_request_id = str(uuid.uuid4())

request_body = ""



x_signature = create_signature(

    webhook_key,

    webhook_secret,

    full_path_and_query,

    x_request_id,

    request_body

)



print("X-Request-ID:", x_request_id)

print("X-Signature:", x_signature)

Webhook 请求格式

Content Format

Webhook 请求的主体包含触发通知的事件相关信息。主体数据的格式由 Content-Type 头决定,通常为 application/json。

请求正文包含以下参数:例子:

XML 复制代码
​
JSON/XML

{

event: "domain_registration",
event_id: 12345,
timestamp: 1700000000000,
data: {4 items}
}

​

参数

请求主体包含以下参数:

|-----------|------------------------------------------------------|
| Parameter | Description |
| event | The type of event that triggered the notification. |
| event_id | The id of the event that triggered the notification. |
| timestamp | The timestamp when the event occurred. |
| data | The data associated with the event. |

Webhook 响应格式

Content Format Webhook请求的响应将以JSON格式发送,具体取决于请求中指定的Content-Type头部。响应体包含请求状态的信息,例如是否成功处理或遇到错误。响应通常包含一个部分:状态例子:

XML 复制代码
JSON/XML

{

Status: "200"
}

速率限制

请求应通过 https(安全套接字)发送以确保安全。一次只能处理一个请求,因此请等待当前请求完成后再发送另一个请求。

您的账户价格等级不同,将获得不同的线程数:

|-------------|--------------|--------------------|
| Price level | Thread Count | Rate Limit |
| Regular | 1 thread | 60/min (1/sec) |
| Bulk | 5 threads | 600/min (10/sec) |
| Super Bulk | 35 threads | 6000/min (100/sec) |

注意:place_auction_bid 和 get_auction_bid 目前不受上述速率限制。

相关推荐
努力攻坚操作系统9 小时前
重新理解 RESTful:从理论约束到工程实践
后端·restful
AIFQuant13 小时前
低延迟金融行情推送优化:WebSocket 心跳、断线重连、流量控制最佳实践(附 Python 代码)
python·websocket·金融·api·数据接口
GuokLiu14 小时前
260528-阿里百炼API测试
api
飞翔中文网1 天前
读RESTful有感,关于Java接口设计规范的说明
java·restful·设计规范
葬送的代码人生2 天前
Notebook环境下的List、Slice与LLM大冒险
python·jupyter·api
XLYcmy2 天前
Agent身份与权限系统设计方案
windows·网络安全·ai·llm·飞书·api·agent
markyankee1012 天前
LLM API 调用与 Prompt 工程基础指南
人工智能·python·api
圣殿骑士-Khtangc3 天前
Python后端开发实战:FastAPI构建高性能RESTful API完整指南
python·restful·fastapi
AIFQuant3 天前
量化交易系统:历史行情 API 批量拉取与回测数据清洗
开发语言·python·金融·restful·量化交易