منصة API لتطوير إنترنت الأشياء

خلاصة القول (TL;DR)

تمتلك واجهات برمجة تطبيقات إنترنت الأشياء (IoT APIs) خصائص تكسر افتراضات أدوات واجهة برمجة التطبيقات القياسية: نطاق ترددي مقيد، وحمولات بيانات ثنائية، وأنماط مصادقة الأجهزة، وبروتوكولات ليست HTTP على الإطلاق. تتناول هذه المقالة ما يحتاجه مطورو إنترنت الأشياء من أدوات واجهة برمجة التطبيقات، وأين تتناسب الأدوات القياسية مثل Apidog، وأين تقصر (MQTT هو المثال الصادق)، وكيفية اختبار الطبقة المواجهة لـ HTTP في الواجهة الخلفية لإنترنت الأشياء لديك بفعالية.

مقدمة

يمتلك تطوير إنترنت الأشياء شخصيتين من حيث واجهات برمجة التطبيقات. من جهة، لديك طبقة الاتصال المواجهة للجهاز: وسطاء MQTT، ونقاط نهاية CoAP، والبروتوكولات الثنائية المخصصة، وتدفقات WebSocket. يتم اختيار هذه البروتوكولات لكفاءة النطاق الترددي، واستهلاك الطاقة المنخفض، وملاءمتها للشبكات المقيدة.

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

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

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

مشهد بروتوكولات إنترنت الأشياء

MQTT: نموذج النشر والاشتراك للأجهزة

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

مفاهيم MQTT الرئيسية: المواضيع (قنوات الرسائل الهرمية)، مستويات جودة الخدمة (QoS) (إرسال ونسيان، مرة واحدة على الأقل، مرة واحدة بالضبط)، الرسائل المحفوظة، رسالة الوداع الأخيرة (LWT) لاكتشاف عدم الاتصال.

لا يدعم Apidog بروتوكول MQTT بشكل أصلي. لاختبار MQTT، استخدم:

• MQTT Explorer: واجهة مستخدم رسومية لسطح المكتب للتفاعل مع وسيط MQTT
• MQTTX: عميل MQTT متعدد المنصات مع إمكانية البرمجة النصية
• mosquitto_sub/mosquitto_pub: أدوات سطر الأوامر من مشروع Mosquitto
• HiveMQ Broker (الطبقة المجانية): وسيط MQTT سحابي مع عميل ويب مدمج

إذا كنت تقوم ببناء نظام إنترنت الأشياء يعتمد على MQTT، فخصص وقتًا لأداة اختبار MQTT مخصصة جنبًا إلى جنب مع أداة REST API.

HTTP/REST: طبقة المنصة

كل منصة إنترنت الأشياء لديها سطح REST API، حتى لو لم تستخدم الأجهزة REST للقياس عن بعد. يتعامل REST مع:

• توفير الأجهزة: التسجيل، وتوليد الشهادات، وتعيين الهوية
• تحديثات البرامج الثابتة عبر الهواء (OTA): التحقق من التحديثات، وتنزيل حزم البرامج الثابتة
• دفع التكوين: إرسال بيانات التكوين إلى الأجهزة أو مجموعات الأجهزة
• استيعاب القياس عن بعد: تقبل بعض منصات إنترنت الأشياء القياس عن بعد عبر HTTP POST (AWS IoT، Particle، العديد من الآخرين)
• إدارة الأجهزة: حالة الأسطول، الأوامر عن بعد، تجميع الأجهزة
• استعلام البيانات: القياس عن بعد التاريخي، سجلات الأحداث، سجل التنبيهات
• تسجيل Webhook: تكوين تسليم الأحداث الصادرة إلى تطبيقك

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

WebSocket: الاتصال ثنائي الاتجاه للجهاز

يقع WebSocket بين REST (بلا حالة، طلب-استجابة) وMQTT (وساطة وسيط، نشر-اشتراك). تستخدم بعض منصات إنترنت الأشياء WebSocket من أجل:

• تدفقات أوامر الجهاز (تسليم الأوامر في الوقت الفعلي إلى جهاز متصل)
• عرض القياس عن بعد المباشر (تدفق بيانات المستشعر إلى واجهة مستخدم إدارية)
• تحديثات التكوين ثنائية الاتجاه

يدعم Apidog اختبار WebSocket مع دعم رؤوس الاتصال، والذي يغطي معظم سيناريوهات إنترنت الأشياء المستندة إلى WebSocket.

CoAP: الأجهزة المقيدة

CoAP (بروتوكول التطبيقات المقيدة) هو بروتوكول شبيه بـ HTTP مصمم للمتحكمات الدقيقة والشبكات المقيدة جدًا. يعمل عبر UDP بدلاً من TCP.

لا يدعم Apidog بروتوكول CoAP. لاختبار CoAP، استخدم copper4cr (امتداد للمتصفح) أو أدوات سطر الأوامر libcoap.

الحمولات الثنائية

تستخدم العديد من بروتوكولات إنترنت الأشياء ترميزًا ثنائيًا بدلاً من JSON: مثل Protocol Buffers، MessagePack، CBOR، أو تنسيقات ثنائية مخصصة. الترميز الثنائي ضروري للسيناريوهات المقيدة بالنطاق الترددي حيث يرسل المستشعر آلاف القراءات يوميًا عبر اتصال خلوي مدفوع.

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

أنماط مصادقة الأجهزة في إنترنت الأشياء

تختلف مصادقة أجهزة إنترنت الأشياء عن مصادقة واجهة برمجة تطبيقات الويب النموذجية. تدعم أدوات واجهة برمجة التطبيقات للأغراض العامة OAuth 2.0، ورموز Bearer، ومفاتيح API، ولكن إنترنت الأشياء يضيف:

بروتوكول أمان طبقة النقل المتبادل (mTLS)

تستخدم العديد من منصات إنترنت الأشياء (AWS IoT Core، Azure IoT Hub، Google Cloud IoT Core) بروتوكول أمان طبقة النقل المتبادل (mTLS) لمصادقة الأجهزة. يمتلك كل جهاز شهادة عميل صادرة أثناء التوفير. يقدم الجهاز هذه الشهادة عند الاتصال.

يتطلب اختبار نقاط نهاية mTLS تحميل شهادة عميل ومفتاح خاص. يدعم Apidog تكوين شهادة العميل لاتصالات TLS، لذا يمكنك اختبار نقاط نهاية mTLS عن طريق تحميل ملفات شهادة جهازك.

مفاتيح API خاصة بالجهاز

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

رموز JWT مع مطالبات الجهاز

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

مصادقة الرأس المخصصة

تستخدم بعض منصات إنترنت الأشياء الاحتكارية رؤوس مصادقة غير قياسية. يدعم Apidog رؤوسًا مخصصة عشوائية، لذا فإن رؤوس المصادقة الخاصة بالمنصة مثل X-Device-Token أو X-Device-Serial تكون مباشرة.

اختبار واجهات برمجة تطبيقات IoT REST باستخدام Apidog

هنا حيث يقدم Apidog قيمة حقيقية لتطوير الواجهة الخلفية لـ IoT.

تدفقات توفير الجهاز

غالبًا ما يكون توفير إنترنت الأشياء تدفق REST متعدد الخطوات:

1. طلب تسجيل الجهاز (POST مع الرقم التسلسلي للجهاز، والنموذج، وإصدار البرنامج الثابت)
2. استلام معرف الجهاز وبيانات الاعتماد في الاستجابة
3. تكوين الجهاز باستخدام بيانات الاعتماد المستلمة
4. التحقق من حالة التسجيل (GET حالة الجهاز)

يدعم Apidog الطلبات المتسلسلة مما يجعل هذا قابلاً للاختبار من البداية إلى النهاية. يستخرج نص برمجي بعد الطلب في الخطوة 1 معرف الجهاز ويخزنه كمتغير بيئة. تستخدم الخطوة 3 هذا المتغير في عنوان URL للطلب. يتم تشغيل تدفق التوفير الكامل كتسلسل.

نقاط نهاية تحديث البرامج الثابتة عبر الهواء (OTA)

تتضمن تدفقات تحديث OTA عادةً ما يلي:

1. GET /devices/{id}/update-check – يعيد ما إذا كان التحديث متاحًا
2. GET /devices/{id}/firmware – يعيد عنوان URL لتنزيل البرنامج الثابت أو الثنائي
3. POST /devices/{id}/update-status – يبلغ عن نتيجة التثبيت

اختبار هذه الأمور باستخدام Apidog مباشر. بالنسبة لاستجابة الثنائية للبرنامج الثابت، يمكنك فحص الرؤوس (Content-Type، Content-Length) والتحقق من أن الاستجابة هي التنسيق الثنائي المتوقع.

استيعاب القياس عن بعد عبر HTTP

تقبل العديد من المنصات القياس عن بعد عبر HTTP POST. قد تكون الحمولة JSON، ولكنها بشكل متزايد ثنائية (Protocol Buffers، MessagePack) لكفاءة النطاق الترددي.

لاختبار استيعاب القياس عن بعد الثنائي باستخدام Apidog:

1. اضبط نوع نص الطلب على raw
2. اختر binary كتنسيق للنص
3. الصق حمولتك المرمزة بنظام سداسي عشري أو Base64
4. اضبط Content-Type: application/octet-stream (أو النوع المتوقع لمنصتك)
5. أرسل وافحص الاستجابة

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

الاختبار باستخدام شهادات SSL مخصصة

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

• تعطيل التحقق من SSL للتطوير المحلي (شهادات موقعة ذاتيًا على خوادم التطوير)
• تحميل شهادة CA مخصصة للتحقق من CA خاص
• تحميل شهادة عميل لاختبار mTLS

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

اختبار WebSocket لتدفقات أجهزة إنترنت الأشياء

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

تدفقات ظلال / توائم الأجهزة: توفر بعض المنصات (AWS IoT، Azure IoT) نقاط نهاية WebSocket التي تبث تحديثات ظلال الأجهزة. عندما يبلغ الجهاز عن حالة، تعكس السحابة ذلك عبر اتصال WebSocket للعملاء المشتركين.

تدفقات القياس عن بعد المباشرة: تتصل لوحات معلومات عرض بيانات المستشعر في الوقت الفعلي عبر WebSocket بنقطة نهاية تدفق القياس عن بعد.

تسليم الأوامر: تسلم بعض المنصات الأوامر في الوقت الفعلي إلى الأجهزة المتصلة عبر WebSocket بدلاً من انتظار الجهاز للاستعلام.

اختبار هذه الأمور باستخدام عميل WebSocket في Apidog:

1. الاتصال بعنوان URL لـ WebSocket باستخدام رؤوس المصادقة المطلوبة (عادةً رمز Bearer أو مفتاح API)
2. إرسال رسالة اشتراك إذا كان البروتوكول يتطلب ذلك (مثل الاشتراك في تدفق أحداث جهاز)
3. مراقبة تدفق الرسائل الواردة في سجل الرسائل
4. إرسال رسائل أوامر اختبار والتحقق من سلوك جانب الجهاز

بالنسبة للمنصات التي تستخدم بروتوكولات فرعية (رأس Sec-WebSocket-Protocol)، يدعم Apidog تحديد البروتوكولات الفرعية في تكوين الاتصال.

ماذا تستخدم لاختبار MQTT

نظرًا لأن Apidog لا يدعم MQTT، فإليك إعداد اختبار MQTT عملي:

يعد MQTTX العميل الأكثر قدرة لـ MQTT بشكل عام. يحتوي على واجهة مستخدم رسومية لسطح المكتب، ويدعم جميع إصدارات بروتوكول MQTT (3.1.1 و 5.0)، ويتعامل مع اتصالات TLS/mTLS، ويتضمن وضع برمجة نصية لتسلسلات الرسائل المؤتمتة. لاختبار MQTT التفاعلي، يعتبر MQTTX أفضل نقطة انطلاق.

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

أدوات سطر الأوامر mosquitto CLI tools (mosquitto_pub, mosquitto_sub) متاحة على معظم أجهزة التطوير (عبر مدير الحزم) وتعمل بشكل جيد للاختبارات السريعة المكتوبة. إذا كنت بحاجة إلى تمرير بيانات الاختبار إلى موضوع MQTT أو الاشتراك وتسجيل الرسائل الواردة، فإن أدوات سطر الأوامر غالبًا ما تكون أسرع من الواجهة الرسومية.

لدمج CI/CD، يعد رمز الاختبار المخصص الذي يستخدم مكتبة MQTT الأصلية للغة (paho-mqtt لـ Python، MQTT.js لـ Node) هو النهج الأكثر مرونة.

إعداد اختبار عملي للواجهة الخلفية لإنترنت الأشياء

هيكل بيئة Apidog:

Environments:
  local-dev: base_url = http://localhost:8080, ssl_verify = false
  staging: base_url = https://iot-staging.example.com, ssl_verify = true
  prod: base_url = https://api.iot.example.com, ssl_verify = true

Variables:
  device_id = dev_test_001
  device_serial = SN-TEST-00001
  auth_token = {{fetched via pre-request script}}
  firmware_version = 2.1.4

هيكل المجلدات:

• provisioning/ – تدفقات تسجيل الأجهزة وإصدار بيانات الاعتماد
• telemetry/ – اختبارات نقطة نهاية الاستيعاب (JSON وأنواع ثنائية)
• ota/ – تدفقات التحقق من تحديث البرامج الثابتة وتسليمها
• device-management/ – عمليات CRUD على سجلات الأجهزة
• websocket/ – اختبارات الاتصال في الوقت الفعلي
• error-cases/ – بيانات اعتماد غير صالحة، رموز منتهية الصلاحية، حمولات مشوهة

قائمة التحقق لاختبار الحمولة الثنائية:

• اختبار بحمولة ثنائية صالحة (المسار الصحيح)
• اختبار بحمولة ثنائية مبتورة (رسالة غير مكتملة)
• اختبار برأس Content-Type خاطئ
• اختبار حجم الحمولة عند الحد الأقصى الموثق لمنصتك
• اختبار بمصادقة جهاز صحيحة وغير صحيحة

الأسئلة الشائعة

هل يدعم Apidog اختبار MQTT؟لا. لا يدعم Apidog بروتوكول MQTT بشكل أصلي. لاختبار MQTT، استخدم MQTTX، MQTT Explorer، أو أدوات سطر الأوامر mosquitto. يغطي Apidog طبقات HTTP و WebSocket في الواجهة الخلفية لإنترنت الأشياء لديك، وليس طبقة وسيط MQTT.

هل يمكن لـ Apidog اختبار نقاط نهاية CoAP؟لا. يعمل CoAP عبر UDP، وهو ما لا يدعمه Apidog. لاختبار CoAP، استخدم copper4cr أو libcoap.

كيف يمكنني اختبار حمولات protobuf الثنائية في Apidog؟قم بترميز رسالة protobuf الخاصة بك إلى ثنائي باستخدام مكتبة protobuf بلغتك، ثم حولها إلى نظام سداسي عشري أو Base64. في Apidog، اضبط النص إلى ثنائي خام والصق الحمولة المرمزة. اضبط Content-Type على application/protobuf أو ما تتوقعه منصتك.

هل يدعم Apidog mTLS لمصادقة شهادة الجهاز؟نعم. تسمح لك إعدادات SSL في Apidog بتحميل شهادة عميل ومفتاح خاص لاتصالات mTLS. وهذا يغطي اختبار نقاط النهاية التي تتطلب مصادقة شهادة الجهاز.

هل يمكننا استخدام Apidog لاختبار AWS IoT Core، Azure IoT Hub، أو Google Cloud IoT؟نعم، بالنسبة لواجهات برمجة تطبيقات REST HTTP لهذه المنصات. لدى AWS IoT Core واجهات برمجة تطبيقات إدارة REST، ولدى Azure IoT Hub نقاط نهاية REST لإدارة الأجهزة واستدعاء الأساليب المباشرة، ولدى Google Cloud IoT Core واجهات برمجة تطبيقات REST. جميعها قابلة للاختبار باستخدام Apidog. تتطلب اتصالات MQTT بهذه المنصات MQTTX أو ما شابه ذلك.

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

يمتد تطوير الواجهة الخلفية لإنترنت الأشياء إلى بروتوكولات لا تغطيها أداة واحدة بالكامل. الإجابة الصادقة هي أنك تحتاج إلى أداتين على الأقل: واحدة لاختبار MQTT والأخرى لـ REST/WebSocket. يتعامل Apidog مع طبقة HTTP بشكل شامل – التوفير، الإدارة، استيعاب القياس عن بعد، الحمولات الثنائية، mTLS، وتدفقات WebSocket. أما بالنسبة لـ MQTT، فإن MQTTX أو mosquitto يسد الفجوة. معرفة الأداة المناسبة التي يجب استخدامها ومتى يكون أكثر فائدة من التظاهر بأن أداة واحدة تغطي كل شيء.