تحديد السرعة مقابل الحد الأقصى

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

💡

تواجه معظم أدوات واجهات برمجة التطبيقات قيودًا عند استخدامها - طلبات محدودة يجب تقديمها، حالات اختبار محدودة يجب إعدادها، وهكذا. ومع ذلك، هناك أداة واجهات برمجة تطبيقات تتجاوز كل هذه القيود.

نقدم لكم Apidog، أداة تطوير واجهات برمجة التطبيقات الشاملة التي تتيح لك اختبار واجهات برمجة التطبيقات بلا حدود. القيد الوحيد الذي تملكه Apidog هو القيد الذي تفرضه واجهات برمجة التطبيقات التابعة لجهات خارجية (سواء كانت ستخنق واجهات برمجة التطبيقات الخاصة بها أم لا).

إذا كنت مهتمًا بتجربة Apidog، ابدأ مجانًا اليوم (أو في المستقبل) بالنقر على الزر أدناه! 👇 👇 👇

button

للتعرف على الفرق بين الاختناق وتحديد المعدل، سنحدد كل منهما بشكل فردي.

ما هو الاختناق؟

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

الميزات الرئيسية للاختناق في واجهات برمجة التطبيقات

1. التعديلات الديناميكية:

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

2. التقنيات والخوارزميات:

دلو مُسرب: تمتلئ الطلبات الواردة بدلو افتراضي مع تسرب صغير في الأسفل. تزداد أوقات الاستجابة (يتباطأ التسرب) مع امتلاء الدلو (اقتراب النظام من التحميل الزائد)، والعكس.
أكوام الرموز: للمستخدمين عدد محدود من الرموز (الطلبات) في إطار زمني محدد. تستهلك كل طلب رمزًا. إذا لم تتوفر رموز (بقاء الدلو فارغًا)، يتم اختناق الطلب حتى يتم تجديد رمز.

3. خيارات التكوين:

التفصيل: يمكن تطبيق الاختناق على مستوى عالمي أو على نقاط نهاية واجهة برمجة التطبيقات المحددة بناءً على استخدام مواردها.
الحدود: تحدد الحدود القابلة للتخصيص متى يبدأ الاختناق. يمكن أن تكون هذه مستندة إلى عوامل مثل الطلبات المتزامنة أو استخدام الموارد.
نوافذ الوقت: يمكن تكوين سلوك الاختناق لفترات زمنية محددة (مثل ساعات الذروة).

4. آليات الاستجابة:

تخفيض السرعة: الطريقة الأكثر شيوعًا، زيادة أوقات الاستجابة للطلبات اللاحقة.
رموز الخطأ: إعادة رموز خطأ HTTP محددة (مثل 429 طلبات كثيرة جدًا) للإشارة إلى الاختناق وخيارات إعادة المحاولة المحتملة.
طوابير الانتظار: الاحتفاظ مؤقتًا بالطلبات في قائمة انتظار حتى تتوفر الموارد.

5. الميزات المتقدمة:

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

مثال على شفرة الاختناق في واجهات برمجة التطبيقات

1. اختناق واجهة برمجة تطبيقات بسيطة مع تأخير (بايثون):

def handle_request(user_id):
  # محاكاة التحقق من عداد مورد مشترك
  if resource_counter > threshold:
    time.sleep(delay_time)  # اختناق من خلال إدخال تأخير
  # معالجة منطق الطلب هنا...

2. اختناق دلو الرموز لطلبات واجهة برمجة التطبيقات (بايثون)

from threading import Lock

class TokenBucket:
  """
  فصل دلو الرموز البسيط لتحديد المعدل.
  """
  def __init__(self, capacity, refill_rate):
    """
    تهيئة دلو الرموز بسعة معينة ومعدل تجديد.

    Args:
      capacity (int): العدد الأقصى من الرموز التي يمكن أن يحملها الدلو.
      refill_rate (float): معدل إضافة الرموز إلى الدلو (رموز في الثانية).
    """
    self.capacity = capacity
    self.refill_rate = refill_rate
    self.tokens = capacity  # بدءًا بدلو مليء
    self.last_refill_time = time.time()
    self.lock = Lock()

  def consume(self, amount):
    """
    يحاول استهلاك عدد معين من الرموز من الدلو.

    Args:
      amount (int): عدد الرموز للاستهلاك.

    Returns:
      bool: صحيح إذا تم استهلاك الرموز بنجاح، خطأ بخلاف ذلك.
    """
    with self.lock:
      self._refill()
      if self.tokens >= amount:
        self.tokens -= amount
        return True
      return False

  def _refill(self):
    """
    يجدد الدلو بناءً على الوقت المنقضي ومعدل التجديد.
    """
    now = time.time()
    elapsed_time = now - self.last_refill_time
    self.tokens = min(self.capacity, self.tokens + (elapsed_time * self.refill_rate))
    self.last_refill_time = now

# استخدام مثال
bucket = TokenBucket(capacity=5, refill_rate=1)  # 5 رموز، متجددة بمعدل 1 رمز/ثانية

def access_api():
  # محاكاة منطق طلب واجهة برمجة التطبيقات هنا...
  print("الوصول إلى واجهة برمجة التطبيقات...")

if bucket.consume(2):
  access_api()
else:
  print("تم اختناق الطلب، لا توجد رموز كافية!")

# حاول مرة أخرى بعد تأخير قصير
time.sleep(1)

if bucket.consume(1):
  access_api()
else:
  print("تم اختناق الطلب، لا توجد رموز كافية!")

تفسير الشفرة (خطوة بخطوة):

أولًا، قم بتعريف TokenBucket class الذي يدير مجموعة الرموز
يأخذ السعة (الحد الأقصى من الرموز) ومعدل التجديد (الرموز في الثانية) كوسائط.
تحاول طريقة consume إزالة عدد معين من الرموز من الدلو.
تقوم باستدعاء الطريقة الخاصة _refill لضمان تحديث الدلو بناءً على الوقت الماضي.
إذا كانت الرموز كافية، يتم استهلاكها - ترجع الطريقة True
بخلاف ذلك، ترجع الطريقة False - يشير إلى الاختناق.

ما هو تحديد المعدل؟

في سياق واجهات برمجة التطبيقات، يشير تحديد المعدل إلى تقييد معين على عدد الطلبات التي يمكن أن يقدمها مستخدم أو تطبيق خلال فترة زمنية محددة. تخيل ذلك كما لو كان في نافذة التذاكر في معلم شهير، حيث يُسمح بعدد معين من الطلبات في الدقيقة.

الميزات الرئيسية لتحديد المعدل في واجهات برمجة التطبيقات

1. تكوين الحدود:

حدود الطلب: تحدد مزودي واجهات برمجة التطبيقات العدد الأقصى من الطلبات المسموح بها لكل مستخدم أو تطبيق خلال فترة زمنية محددة (مثل 100 طلب في الساعة). يمكن أن تستند هذه الحدود إلى عوامل مثل:

فئات المستخدمين: قد تحتوي الخطط المجانية والمدفوعة على حدود مختلفة.
نقاط نهاية واجهة برمجة التطبيقات: قد تحتوي الوظائف المختلفة على متطلبات موارد مختلفة، مما يؤدي إلى حدود مختلفة.

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

2. آليات العد:

تحديد هوية المستخدم: ترتبط الطلبات بمستخدمين أو تطبيقات. يمكن تحقيق ذلك من خلال:

مفاتيح واجهة برمجة التطبيقات: معرفات فريدة مقدمة للمطورين للمصادقة وتتبع الاستخدام.
عناوين IP: على الرغم من أنها أقل أمانًا، إلا أنه يمكن استخدام عناوين IP لتحديد المعدل الأساسي.

عدادات الطلب: تحتفظ واجهة برمجة التطبيقات بسجل لعدد الطلبات التي تم استلامها من كل مستخدم/تطبيق ضمن نافذة الوقت الحالية.

3. استراتيجيات التطبيق:

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

4. الميزات المتقدمة:

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

5. التواصل والمراقبة:

توثيق واجهة برمجة التطبيقات: يوضح التوثيق الواضح حدود المعدل، بما في ذلك الحدود المحددة، ونوافذ الوقت، وطرق التطبيق.
المراقبة والتنبيهات: تراقب مزودي واجهة برمجة التطبيقات أنماط الاستخدام وتعدل حدود المعدل حسب الحاجة للحفاظ على الاستقرار.

أمثلة شفرة تحديد المعدل في واجهات برمجة التطبيقات

1. تتبع الحدود ونوافذ الوقت (بايثون):

# محاكاة تخزين معلومات حد المعدل المسترجعة من التوثيق
rate_limit = 100  # الطلبات في الساعة
time_window = 3600  # ثواني في الساعة

last_request_time = None

def make_api_request():
  global last_request_time

  # التحقق مما إذا كنت ضمن نافذة الوقت وما إذا كانت هناك طلبات كافية متبقية (افتراضى)
  if last_request_time is None or (time.time() - last_request_time) >= time_window:
    # إجراء الطلب
    last_request_time = time.time()
    # ... (منطق طلب واجهة برمجة التطبيقات)
  else:
    print("تم الوصول إلى حد معدل واجهة برمجة التطبيقات، انتظر لإعادة الضبط...")
    # تنفيذ استراتيجية التراجع (انظر النقطة 3)

# استخدام مثال
make_api_request()

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

2. استخدام رؤوس استجابة واجهة برمجة التطبيقات (بايثون):

import requests

def make_api_request():
  response = requests.get("https://api.example.com/data")
  if response.status_code == 429:  # رمز تجاوز حد المعدل
    # استخراج معلومات حدود المعدل من الرؤوس (X-RateLimit-Remaining، X-RateLimit-Reset)
    # تنفيذ استراتيجية التراجع (انظر النقطة 3)
  else:
    # معالجة الاستجابة الناجحة
    # ...

يتحقق مثال الشفرة أعلاه من رمز حالة الاستجابة لعرض شائع لخطأ حد المعدل 429 ويحاول استخراج المعلومات ذات الصلة من رؤوس الاستجابة إذا تمت مواجهته.

الاختلافات الملخصة بين الاختناق وتحديد المعدل

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

Apidog - طلبات غير محدودة لإتقان تطبيقك

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

button

تعرف على Apidog، أداة تطوير واجهات برمجة التطبيقات الشاملة التي تسهل كل عملية تطوير واجهة برمجة التطبيقات لدورة حياة واجهة برمجة التطبيقات الكاملة. مع Apidog، يمكنك إنشاء واجهات برمجة تطبيقات جديدة وتعديل واجهات برمجة التطبيقات الحالية، وإجراء اختبارات، ومحاكاة، وتوثيق لضمان أن واجهات برمجة التطبيقات الخاصة بك ستعمل بسلاسة.

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

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

ابدأ بالضغط على زر New API، كما هو موضح في الصورة أعلاه.

بعد ذلك، يمكنك اختيار العديد من خصائص واجهة برمجة التطبيقات. في هذه الصفحة، يمكنك:

تعيين طريقة HTTP (GET، POST، PUT، أو DELETE)
تعيين عنوان URL الخاص بواجهة برمجة التطبيقات (أو نقطة نهاية واجهة برمجة التطبيقات) لتفاعل العميل والخادم
تضمين معلمة واحدة / متعددة ليتم تمريرها في عنوان URL الخاص بواجهة برمجة التطبيقات
تقديم وصف للوظيفة التي تهدف واجهة برمجة التطبيقات إلى توفيرها. هنا، يمكنك أيضًا وصف حد المعدل الذي تخطط لتطبيقه على واجهتك.

كلما زادت التفاصيل التي يمكنك تقديمها لمرحلة التصميم، كلما كانت الوثائق الخاصة بواجهة برمجة التطبيقات الخاصة بك أكثر وصفًا، كما هو موضح في القسم التالي من هذه المقالة.

تأكد من تضمين ما إذا كان هناك أي حدود معدل مفروضة على واجهة برمجة التطبيقات، حيث سيحتاج المستخدمون إلى تلك المعرفة للعمل مع واجهة برمجة التطبيقات.

لتوفير بعض المساعدة في إنشاء واجهات برمجة التطبيقات في حالة كانت هذه هي المرة الأولى لك في إنشاء واحدة، قد تفكر في قراءة هذه المقالات.

بمجرد الانتهاء من جميع الاحتياجات الأساسية لتقديم طلب، يمكنك محاولة تقديم الطلب عن طريق النقر على Send. يجب أن تتلقى استجابة في الجزء السفلي من نافذة Apidog، كما هو موضح في الصورة أعلاه.

تتيح واجهة المستخدم البسيطة والبديهية للمستخدمين رؤية الاستجابة الناتجة عن الطلب بسهولة. من المهم أيضًا فهم هيكل الاستجابة حيث تحتاج إلى مطابقة الشفرة على كلا من جانب العميل والخادم.

إنشاء توثيق شامل لواجهة برمجة التطبيقات باستخدام Apidog

مع Apidog، يمكنك بسرعة إنشاء توثيق لواجهة برمجة التطبيقات يتضمن كل ما يحتاجه المطورون في بضع نقرات فقط.

عملية خطوة بخطوة لمشاركة وثائق واجهة البرمجة Apidog

السهم 1 - أولاً، اضغط على زر Share على الجانب الأيسر من نافذة تطبيق Apidog. يجب أن تتمكن بعد ذلك من رؤية صفحة "المستندات المشتركة"، والتي يجب أن تكون فارغة.

السهم 2 - اضغط على زر + New تحت No Data لبدء إنشاء أول وثيقة لواجهة برمجة التطبيقات الخاصة بك في Apidog.

حدد وضمن الخصائص الهامة لوثائق واجهة برمجة التطبيقات

إدخال تفاصيل واجهة برمجة التطبيقات واختيار خصائص الوثائق Apidog

توفر Apidog للمطورين خيار اختيار خصائص توثيق واجهة برمجة التطبيقات، مثل من يمكنه عرض توثيق واجهة برمجة التطبيقات الخاصة بك وتعيين كلمة مرور لملف، بحيث لا يمكن عرضها إلا من قبل أفراد أو منظمات مختارة.

عرض أو مشاركة توثيق واجهة برمجة التطبيقات الخاصة بك

فتح مشاركة وثائق واجهة برمجة التطبيقات لتعديلها Apidog

تقوم Apidog بتجميع تفاصيل مشروع واجهة برمجة التطبيقات الخاصة بك في وثائق يمكن عرضها من خلال عنوان ويب. كل ما عليك فعله هو توزيع عنوان URL حتى يتمكن الآخرون من عرض الوثائق الخاصة بواجهة برمجة التطبيقات الخاصة بك!

إذا كنت بحاجة إلى مزيد من التفاصيل، اقرأ هذا المقال حول كيفية إنشاء توثيق واجهة برمجة التطبيقات باستخدام Apidog:

خاتمة

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

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

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

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

button