واجهة برمجة تطبيقات المجال - قائمة أوامر واجهة برمجة التطبيقات

واجهة برمجة تطبيقات Dynadot

البدء باستخدام واجهة برمجة التطبيقات RESTful الخاصة بنا

واجهة برمجة تطبيقات Dynadot مصممة للتكامل السلس مع أنظمتكم. تتميز واجهة البرمجة لدينا بعناوين URL الموجهة نحو الموارد والتي يمكن التنبؤ بها، وتدعم أجسام الطلب المشفرة بصيغة JSON، وتعيد الاستجابات المشفرة بصيغتي JSON وXML، وتلتزم بالطرق القياسية لبروتوكول HTTP وأساليب المصادقة وأكواد الاستجابة.يمكنك استخدام واجهة برمجة التطبيقات (API) الخاصة بـ Dynadot في كل من الوضع التجريبي والوضع الحي. يتم تحديد الوضع بواسطة مفتاح API المستخدم لمصادقة طلباتك. يتيح لك الوضع التجريبي محاكاة والتحقق من تكامل API الخاص بك دون التأثير على البيانات الحية أو المعاملات.واجهة برمجة تطبيقات Dynadot تركز بشكل أساسي على إدارة النطاقات، معالجة الطلبات، والخدمات ذات الصلة. يمكنك تنفيذ إجراءات مثل تسجيل، نقل، وتجديد النطاقات، إدارة إعدادات DNS، ومشاهدة أو تحديث طلبات الحساب.يرجى الانتباه: لا يتم دعم الإنشاءات، التحديثات، أو الحذف الجماعي، وكل نوع من هذه الطلبات محدود بعنصر واحد أو إجراء واحد.

إنشاء مفاتيح 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

عنوان URL الأساسي لجميع طلبات API هو:https://api.dynadot.com/

صيغة الرابط الكاملة:http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action

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

Certainly! Here is the translation: النسخة

النسخة الحالية من واجهة برمجة التطبيقات هي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-Signatureرأس X-Signature هو آلية أمان إلزامية لطلبات المعاملات، بما في ذلك تلك التي تسترجع معلومات حساسة أو تحدث البيانات. يضمن هذا الرأس صحة وسلامة وعدم إنكار طلبات API من خلال مطالبة العملاء بتوقيع حمولة الطلب باستخدام HMAC-SHA256.

لتوليد التوقيع، ستحتاج إلى القيم التالية1. مفتاح API: مفتاح API الفريد الخاص بك.2. المسار الكامل والاستعلام: المسار الكامل لنقطة نهاية API بالإضافة إلى معاملات الاستعلام.3. X-Request-Id: معرّف الطلب. إذا لم يكن متوفرًا، يمكنك إدخال سلسلة فارغة.4. جسم الطلب: محتوى الطلب. إذا كان فارغًا أو غير محدد، يمكنك إدخال سلسلة فارغة.

السلسلة المراد توقيعها هي مزيج من القيم المذكورة أعلاه، متصلة بالترتيب التالي:

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.يرجى استخدام stringToSign كرسالة إدخال.3. استخدم السر كمفتاح.
قم بتطبيق التوقيع المُنشأ كقيمة لـ X-Signature في رأس الطلب

X-Signature: {HMAC-SHA256 Signature}

Bodyيُستخدم نص طلب API لإرسال البيانات إلى الخادم. يُضمّن عادةً في طلبات POST، PUT، أو PATCH (وليس بشكل نموذجي في طلبات GET أو DELETE).

Certainly! Please provide the specific text you need translated into Arabic. The instructions you've given are clear, but I need the actual content to proceed with the translation.تُحدد صيغة بيانات النص الأساسي بواسطة رأس نوع المحتوى. بعض الصيغ الشائعة تشمل:

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

الاستخدامات النموذجيةطلبات POST: يُستخدم أسلوب POST لإنشاء مورد جديد على الخادم. عادةً ما يحتوي جسم الطلب على تفاصيل المورد.طلبات PUT: يُستخدم أسلوب PUT لتحديث مورد موجود من خلال استبداله بالكامل. يحتوي نص الطلب على المورد المُحدث بالكامل.طلبات GET: يُستخدم أسلوب DELETE لإزالة مورد موجود بالفعل من الخادم. لا يحتوي على جسم الطلب.طلبات الحذف: يُستخدم أسلوب الـ GET لاسترجاع مورد موجود مسبقًا من الخادم. لا يحتوي على جسم الطلب

Response Formatجميع استجابات API يتم إرجاعها إما بتنسيق JSON أو XML، ويتم تحديد تنسيق بيانات الجسم بواسطة رأس القبول، والذي يوفر البيانات المطلوبة أو رسالة خطأ، إذا كان ذلك مناسبًا.

Certainly! Please provide the specific text you need translated into Arabic. The instructions you've given are clear, but I need the actual content to proceed with the translation.الرد بشكل عام يحتوي على ثلاثة أجزاء: الرمز، الرسالة، البيانات.

الرمز: حالة الطلبالرسالة: المزيد من التفاصيل حول الحالةالبيانات: محتوى الاستجابة

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

معالجة الأخطاءرموز حالة HTTP هي أرقام مكونة من ثلاثة أرقام موحدة يعيدها الخادم للدلالة على نتيجة طلب العميل. توفر هذه الرموز معلومات أساسية حول ما إذا كان الطلب قد تم معالجته بنجاح، أو يتطلب المزيد من الإجراءات، أو واجه خطأ. تنقسم هذه الرموز إلى خمس فئات، كل منها يمثل نوعًا مختلفًا من الاستجابات.تلتزم أكواد حالة واجهة برمجة التطبيقات الخاصة بنا ببروتوكول 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 (مأخذ توصيل آمن) لضمان الأمان. يمكن معالجة طلب واحد فقط في كل مرة، لذا يرجى الانتظار حتى اكتمال طلبك الحالي قبل إرسال طلب آخر.

ستتلقى عدد خيوط مختلف بناءً على مستوى السعر لحسابك:

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)، الذي يساعد المطورين على تتبع تطور الميزات وضمان التوافق. يتم تحديد كل إصدار من واجهة برمجة التطبيقات برقم إصدار فريد (مثل، v1.0.1، v2.2.3) ويمثل علامة بارزة أو إصداراً مهماً. يتيح الإصدار للمستخدمين الحفاظ على التكاملات بأقل قدر من الانقطاع من خلال اختيار التحديثات عند الاستعداد لذلك.

سجل تاريخ التغييراتسجل التغييرات التاريخي يوفر معلومات مفصلة حول التحديثات، إصلاح الأخطاء، الإهمالات، والتحسينات التي تم إدخالها في كل إصدار. يوضح التغييرات المحددة التي تم إجراؤها على نقاط النهاية، المعاملات، آليات المصادقة، أو تنسيقات الاستجابة. تضمن هذه القسم أن يكون لدى المطورين شفافية كاملة حول ما تغير ويمكنهم تعديل تنفيذهم وفقًا لذلك. من خلال الحفاظ على سجل تغييرات واضح ومفصل، نهدف إلى تزويد المطورين بالأدوات والمعلومات اللازمة لإدارة التكاملات بفعالية وثقة.

إصدار API

نسخة واجهة برمجة التطبيقات (API) الحالية لدينا هيv

تُستخدم رموز الإصدارات لتحديد وإدارة تحديثات واجهة برمجة التطبيقات (API) بشكل منهجي. وهي تتبع تنسيق الإصدار الدلالي (SemVer):

كل مكون من مكونات رمز الإصدار يخدم غرضًا محددًا ويساعد المطورين على التواصل بفعالية حول نطاق التغييرات ونوعها.

الإصدار الرئيسيالتعريف: يُمثل تغييرات جوهرية قد تؤدي إلى كسر التوافق مع الإصدارات السابقة.Certainly! Please provide the text you need translated into Arabic.<Major>.x.x

أمثلة:v1.0.0->v2.0.0: إعادة تصميم كاملة لواجهة برمجة التطبيقات أو تغييرات غير متوافقة في المخطط.

الإصدار الفرعيالتعريف: يشير إلى إضافات الميزات المتوافقة مع الإصدارات السابقة.Certainly! Please provide the text you need translated into Arabic.x.<Minor>.x

أمثلة:v1.0.0->v1.1.0: إضافة نقاط نهاية أو طرق جديدة مع الحفاظ على التوافق مع الإصدارات السابقة.

إصدار التصحيحالتعريف: يشير إلى إصلاحات الأخطاء المتوافقة مع الإصدارات السابقة أو التحسينات الطفيفة.Certainly! Please provide the text you need translated into Arabic.x.x.<Patch>

أمثلة:v1.0.0->v1.1.0: إصلاح خلل بسيط في نقطة نهاية API.

سجل تغييرات الواجهة البرمجية (API)

سجل التغييرات هو سجل مفصل للتغييرات، التحسينات، إصلاحات الأخطاء، والميزات الجديدة التي تُقدم في كل إصدار من البرمجيات أو واجهة برمجة التطبيقات (API). يوفر الشفافية للمستخدمين والمطورين من خلال توثيق تأثير كل تحديث.

عادةً ما يتضمن سجل التغييرات البنود التالية:الوصف: شرح موجز لما تم تغييره.المكونات المتأثرة: الوحدات المحددة، نقاط النهاية، أو الميزات التي تأثرت بالتغيير.

مثال: تم إضافة دعم لأمر API الجديد هذا<تسجيل النطاق>

سجل تاريخ التغييراتتابع كل تغيير يطرأ على واجهة برمجة تطبيقات Dynadot.