ドメインAPI- APIコマンドの一覧|ダイナドット

ダイナドットAPI

私たちのRESTful APIの使い方を始めましょう

Dynadot APIは、あなたのシステムとのシームレスな統合を目的としています。私たちのAPIは、予測可能なリソース指向のURLを特徴としており、JSONエンコードされたリクエストボディをサポートし、JSONエンコードおよびXMLエンコードされたレスポンスを返し、標準的なHTTPメソッド、認証、レスポンスコードに準拠しています。Dynadot APIは、テストモードとライブモードの両方で使用できます。モードは、リクエストを認証するために使用されるAPIキーによって決まります。テストモードでは、ライブデータやトランザクションに影響を与えることなく、API統合をシミュレーションし、検証することができます。Dynadot APIは、主にドメイン管理、注文処理、および関連サービスに焦点を当てています。ドメインの登録、移管、更新、DNS設定の管理、アカウントの注文の表示や更新などの操作を行うことができます。ご注意ください: 一括作成、更新、削除はサポートされておらず、各リクエストタイプは1つのオブジェクトまたはアクションに制限されています。

APIキーの生成APIリクエストを開始する前に、APIキーとAPIシークレットを生成することが重要です。これらのキーは、認証に必要であり、APIとやり取りする際のアクションのセキュリティを確保するために重要です。アカウント設定のAPIセクションから、APIキーとAPIシークレットの両方を生成できます。1. Dynadotのアカウントにログインしてください。2. ツール > API に移動します。3. このページからAPIキーとAPIシークレットを生成してください。

コミュニティに参加しようアイデアや提案はありますか？私たちのプロフェッショナルエンジニアに直接お話しください。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

すべてのAPIリクエストの基本URLは次のとおりです:https://api.dynadot.com/

フルURL形式:以下のテキストを日本語に翻訳しますが、自然で会話的なトーンを保ち、www.dynadot.comのサブドメインで一般的に見られる内容に一致するプロフェッショナルなスタイルを維持します。アスタリスク、句読点、HTMLタグ、プレースホルダー（“”、%d、%s、@ld、@d、%.2f、%@）は翻訳せず、そのまま残します。 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 Japanese.

APIの現在のバージョンはv

APIリクエストURLを構築する際には、メジャーバージョンのみを含める必要があります。マイナーバージョンやパッチの更新は後方互換性を持つように設計されており、既存のコードを壊すような変更は行われません。これにより、実装を変更することなく、安定性を保ちながら段階的な改善や修正の恩恵を受けることができます。将来のバージョンがリリースされる際には、一定期間、古いバージョンとの後方互換性を維持します。新機能や破壊的な変更は、メジャーバージョンの増分で導入されます。

HeaderAPIリクエストのヘッダーには、リクエストに関するメタデータが含まれています。このメタデータは、サーバーがリクエストを適切に処理するための重要なコンテキストを提供します。一般的に使用されるヘッダーには次のものがあります：

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-IDX-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-サインatureX-Signatureヘッダーは、機密情報を取得したりデータを更新したりするトランザクションリクエストに対する必須のセキュリティメカニズムです。これは、クライアントがHMAC-SHA256を使用してリクエストペイロードに署名することを要求することで、APIリクエストの真正性、整合性、および否認防止を確保します。

署名を生成するには、次の値が必要です。APIキー: あなたのユニークなAPIキーです。2. フルパスとクエリ: APIエンドポイントのフルパスとクエリパラメータ。3. X-Request-Id: リクエスト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暗号化を適用する必要があります。このプロセスにより、署名が作成されます。署名は以下の手順を使用して生成されます：HMAC-SHA256アルゴリズムを使用してください。Sure! Please provide the text you would like me to translate into Japanese.秘密を鍵として使用してください。
リクエストヘッダーのX-Signatureの値として、生成されたsignatureを適用してください。

X-Signature: {HMAC-SHA256 Signature}

BodyAPIリクエストのボディは、サーバーにデータを送信するために使用されます。これは、一般的にPOST、PUT、またはPATCHリクエストに含まれます（GETやDELETEリクエストには通常含まれません）。

Sure! Please provide the text you would like me to translate into Japanese.ボディデータのフォーマットは、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 Japanese.Sure! Please provide the text you would like me to translate into Japanese.

コード: リクエストのステータスメッセージ: ステータスの詳細説明データ: 返信の本文

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

エラーハンドリングHTTPステータスコードは、クライアントのリクエストの結果を示すためにサーバーから返される標準化された3桁の番号です。これらのコードは、リクエストが正常に処理されたか、さらなるアクションが必要か、またはエラーが発生したかについての重要な情報を提供します。これらのコードは5つのカテゴリに分かれており、それぞれ異なるタイプの応答を表しています。私たちのAPIのステータスコードは、広く受け入れられている標準であるHTTP/1.1プロトコルに準拠しています。HTTP/1.1を使用することで、持続的な接続や強化されたキャッシングなどの機能を活用し、クライアントとサーバー間のインタラクションを最適化しています。

2xx (成功): コマンドが受信され、受け入れられたことを示します

200ステータスコードは、リクエストが成功したことを示しています。

201ステータスコードは、リクエストが正常に処理され、1つ以上の新しいリソースが作成されたことを示しています。

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の各バージョンで導入された変更、改善、バグ修正、新機能の詳細な記録です。これは、各アップデートの影響を文書化することで、ユーザーと開発者に透明性を提供します。変更ログは、2つの主要な部分で構成されています：

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 Japanese.Sure! Please provide the text you would like me to translate into Japanese.Sure! Please provide the text you would like me to translate into Japanese.

バージョンコードの各コンポーネントは特定の目的を持ち、開発者が変更の範囲や種類を効果的に伝えるのに役立ちます。

メジャーバージョン定義：後方互換性を破る可能性のある重要な変更を表します。Sure! Please provide the text you would like me to translate into Japanese.<Major>.x.x

例:v1.0.0->v2.0.0完全なAPIの再設計または互換性のないスキーマ変更。

マイナーバージョン定義：後方互換性のある機能追加を示します。Sure! Please provide the text you would like me to translate into Japanese.x.<Minor>.x

例:v1.0.0->v1.1.0新しいエンドポイントやメソッドを追加しつつ、後方互換性を維持します。

パッチバージョン定義：後方互換性のあるバグ修正や小規模な改善を指します。Sure! Please provide the text you would like me to translate into Japanese.x.x.<Patch>

例:v1.0.0->v1.1.0APIエンドポイントの小さなバグを修正しています。

API変更ログ

変更ログは、ソフトウェアやAPIの各バージョンで導入された変更、改善、バグ修正、新機能の詳細な記録です。これは、各アップデートの影響を文書化することで、ユーザーと開発者に透明性を提供します。

変更ログの一般的なエントリには、次の内容が含まれます：説明: 変更された内容の簡単な説明。影響を受けるコンポーネント: 変更によって影響を受ける特定のモジュール、エンドポイント、または機能。

例: この新しいAPIコマンドのサポートを追加しましたSure! Here’s the translation of the text to Japanese: <ドメイン登録>

変更ログ履歴Dynadot APIのすべての変更を追跡してください。

Chat Online

現在のキュー内のチャット:0

オンラインチャット0

カートを表示

ドメイン

ドメイン検索転送IDNの検索TLD 価格ドメイン販売再販業者ウェブサイトメールSSLドメイン提案ツールセキュリティグレース削除APIWhoisの検索支払いプラン

アフターマーケット

アフターマーケット検索市場概観ユーザーリスト在庫切れ期限切れのオークションユーザーオークションバックオーダーオークションラストチャンスオークション期限切れクローズアウト

サポート

ヘルプファイルドメインの購入ドメイン売買ニュースレター前払い支払いオプション虐待を報告する

ダイナドット

について連絡先イベントサイトマップアプリ友達を紹介するアフィリエイトオークションアフィリエイト