แพลตฟอร์ม API สำหรับพัฒนา IoT

สรุป

API ของ IoT มีลักษณะเฉพาะที่แตกต่างจากเครื่องมือ API ทั่วไป: แบนด์วิธจำกัด, เพย์โหลดแบบไบนารี, รูปแบบการยืนยันตัวตนของอุปกรณ์, และโปรโตคอลที่ไม่ใช่ HTTP เลย บทความนี้จะกล่าวถึงสิ่งที่นักพัฒนา IoT ต้องการจากเครื่องมือ API, จุดที่เครื่องมือมาตรฐานอย่าง Apidog สามารถใช้งานได้, ข้อจำกัด (ตัวอย่างที่ตรงไปตรงมาคือ MQTT), และวิธีการทดสอบเลเยอร์ที่ใช้งาน HTTP ของแบ็กเอนด์ IoT ของคุณอย่างมีประสิทธิภาพ

บทนำ

การพัฒนา IoT มีลักษณะสองด้านเมื่อพูดถึง API ด้านหนึ่งคือเลเยอร์การสื่อสารที่เชื่อมต่อกับอุปกรณ์: โบรกเกอร์ MQTT, เอนด์พอยต์ CoAP, โปรโตคอลไบนารีแบบกำหนดเอง, และสตรีม WebSocket โปรโตคอลเหล่านี้ถูกเลือกเพื่อประสิทธิภาพของแบนด์วิธ, การใช้พลังงานต่ำ, และความเหมาะสมสำหรับเครือข่ายที่มีข้อจำกัด

อีกด้านหนึ่งคือเลเยอร์ที่เชื่อมต่อกับแพลตฟอร์ม: REST API สำหรับการจัดเตรียมอุปกรณ์, การส่งมอบการอัปเดตเฟิร์มแวร์, การนำเข้าข้อมูล telemetry, และแดชบอร์ดการจัดการ ซึ่งมีลักษณะเหมือนกับแบ็กเอนด์เว็บทั่วไป

เครื่องมือ API ส่วนใหญ่รองรับกลุ่มที่สองได้ดีและละเลยกลุ่มแรกโดยสิ้นเชิง นั่นเป็นช่องว่างที่แท้จริง แต่ก็เป็นความจริงที่ตรงไปตรงมา นักพัฒนา IoT ที่คาดหวังว่าแพลตฟอร์ม API ทั่วไปจะรองรับการทดสอบ MQTT โดยกำเนิดจะผิดหวัง แนวทางที่ถูกต้องคือการทำความเข้าใจว่าเครื่องมือ API มาตรฐานของคุณครอบคลุมโปรโตคอลใดบ้าง ใช้งานได้อย่างมีประสิทธิภาพสำหรับโปรโตคอลเหล่านั้น และรู้ว่าควรใช้เครื่องมือเฉพาะทางเมื่อใด

บทความนี้จะสำรวจภูมิทัศน์ของโปรโตคอล IoT, อธิบายสิ่งที่ Apidog รองรับ (และสิ่งที่ไม่รองรับ), และนำเสนอการตั้งค่าการทดสอบที่เป็นประโยชน์สำหรับส่วนแบ็กเอนด์ IoT ที่ทำงานด้วย HTTP

ภูมิทัศน์ของโปรโตคอล IoT

MQTT: publish-subscribe สำหรับอุปกรณ์

MQTT เป็นโปรโตคอลหลักสำหรับการสื่อสารระหว่างอุปกรณ์กับคลาวด์ ถูกออกแบบมาสำหรับเครือข่ายที่ไม่เสถียร, อุปกรณ์ที่มีข้อจำกัด, และการส่งข้อความอย่างมีประสิทธิภาพผ่านโบรกเกอร์

แนวคิดสำคัญของ MQTT: หัวข้อ (ช่องทางข้อความแบบลำดับชั้น), ระดับ QoS (fire-and-forget, at-least-once, exactly-once), ข้อความที่เก็บไว้ (retained messages), และพินัยกรรมสุดท้าย (LWT) สำหรับการตรวจจับสถานะออฟไลน์

Apidog ไม่รองรับ MQTT โดยกำเนิด สำหรับการทดสอบ MQTT ให้ใช้:

• MQTT Explorer: GUI บนเดสก์ท็อปสำหรับการโต้ตอบกับโบรกเกอร์ MQTT
• MQTTX: ไคลเอนต์ MQTT แบบข้ามแพลตฟอร์มพร้อมการเขียนสคริปต์
• mosquitto_sub/mosquitto_pub: เครื่องมือ CLI จากโปรเจกต์ Mosquitto
• HiveMQ Broker (รุ่นฟรี): โบรกเกอร์ MQTT บนคลาวด์พร้อมไคลเอนต์เว็บในตัว

หากคุณกำลังสร้างระบบ IoT ที่ใช้ MQTT ควรเผื่อเวลาสำหรับเครื่องมือทดสอบ MQTT โดยเฉพาะควบคู่ไปกับเครื่องมือ REST API ของคุณ

HTTP/REST: เลเยอร์แพลตฟอร์ม

ทุกแพลตฟอร์ม IoT มีส่วน API แบบ REST แม้ว่าอุปกรณ์จะไม่ใช้ REST สำหรับข้อมูล telemetry ก็ตาม REST จัดการเรื่อง:

• การจัดเตรียมอุปกรณ์: การลงทะเบียน, การสร้างใบรับรอง, การกำหนดตัวตน
• การอัปเดตเฟิร์มแวร์แบบ OTA: การตรวจสอบการอัปเดต, การดาวน์โหลดแพ็กเกจเฟิร์มแวร์
• การพุชการกำหนดค่า: การส่งข้อมูลการกำหนดค่าไปยังอุปกรณ์หรือกลุ่มอุปกรณ์
• การนำเข้าข้อมูล telemetry: แพลตฟอร์ม IoT บางแห่งยอมรับข้อมูล telemetry ผ่าน HTTP POST (AWS IoT, Particle และอื่น ๆ อีกมากมาย)
• การจัดการอุปกรณ์: สถานะกลุ่มอุปกรณ์, คำสั่งระยะไกล, การจัดกลุ่มอุปกรณ์
• การสอบถามข้อมูล: ข้อมูล telemetry ย้อนหลัง, บันทึกเหตุการณ์, ประวัติการแจ้งเตือน
• การลงทะเบียน Webhook: การกำหนดค่าการส่งมอบเหตุการณ์ขาออกไปยังแอปพลิเคชันของคุณ

พื้นที่ทั้งหมดนี้สามารถทดสอบได้ด้วยเครื่องมือ REST มาตรฐาน

WebSocket: การสื่อสารแบบสองทิศทางของอุปกรณ์

WebSocket อยู่ระหว่าง REST (stateless, request-response) และ MQTT (broker-mediated, publish-subscribe) แพลตฟอร์ม IoT บางแห่งใช้ WebSocket สำหรับ:

• สตรีมคำสั่งอุปกรณ์ (การส่งคำสั่งแบบเรียลไทม์ไปยังอุปกรณ์ที่เชื่อมต่อ)
• การแสดงผลข้อมูล telemetry แบบสด (การสตรีมข้อมูลเซ็นเซอร์ไปยัง UI การจัดการ)
• การอัปเดตการกำหนดค่าแบบสองทิศทาง

Apidog รองรับการทดสอบ WebSocket ด้วยการสนับสนุนเฮดเดอร์การเชื่อมต่อ ซึ่งครอบคลุมสถานการณ์ IoT ที่ใช้ WebSocket ส่วนใหญ่

CoAP: อุปกรณ์ที่มีข้อจำกัด

CoAP (Constrained Application Protocol) เป็นโปรโตคอลที่คล้าย HTTP ซึ่งออกแบบมาสำหรับไมโครคอนโทรลเลอร์และเครือข่ายที่มีข้อจำกัดมาก ทำงานบน UDP แทนที่จะเป็น TCP

Apidog ไม่รองรับ CoAP สำหรับการทดสอบ CoAP ให้ใช้ copper4cr (ส่วนขยายเบราว์เซอร์) หรือเครื่องมือ CLI ของ libcoap

เพย์โหลดแบบไบนารี

โปรโตคอล IoT จำนวนมากใช้การเข้ารหัสแบบไบนารีแทน JSON: Protocol Buffers, MessagePack, CBOR หรือรูปแบบไบนารีแบบกำหนดเอง การเข้ารหัสแบบไบนารีมีความสำคัญสำหรับสถานการณ์ที่แบนด์วิธจำกัด ซึ่งเซ็นเซอร์กำลังส่งข้อมูลนับพันรายการต่อวันผ่านการเชื่อมต่อเซลลูลาร์แบบมีค่าใช้จ่าย

Apidog รองรับเนื้อหาคำขอแบบไบนารีดิบ คุณสามารถส่งเพย์โหลดไบนารีที่เข้ารหัสแบบ hex หรือ base64 ในคำขอ HTTP ซึ่งครอบคลุมกรณีที่แพลตฟอร์ม IoT ของคุณยอมรับไบนารีผ่าน HTTP

รูปแบบการยืนยันตัวตนของอุปกรณ์ใน IoT

การยืนยันตัวตนสำหรับอุปกรณ์ IoT แตกต่างจากการยืนยันตัวตน API เว็บทั่วไป เครื่องมือ API ทั่วไปรองรับ OAuth 2.0, Bearer tokens และ API keys แต่ IoT เพิ่มเติม:

Mutual TLS (mTLS)

แพลตฟอร์ม IoT หลายแห่ง (AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core) ใช้ mutual TLS สำหรับการยืนยันตัวตนของอุปกรณ์ อุปกรณ์แต่ละเครื่องมีใบรับรองไคลเอนต์ที่ออกให้ในระหว่างการจัดเตรียมอุปกรณ์ อุปกรณ์จะนำเสนอใบรับรองนี้เมื่อเชื่อมต่อ

การทดสอบเอนด์พอยต์ mTLS ต้องมีการโหลดใบรับรองไคลเอนต์และคีย์ส่วนตัว Apidog รองรับการกำหนดค่าใบรับรองไคลเอนต์สำหรับการเชื่อมต่อ TLS ดังนั้นคุณจึงสามารถทดสอบเอนด์พอยต์ mTLS ได้โดยการโหลดไฟล์ใบรับรองอุปกรณ์ของคุณ

API keys เฉพาะอุปกรณ์

แพลตฟอร์ม IoT แบบง่ายมักจะออก API keys หรือคู่โทเค็นสำหรับแต่ละอุปกรณ์ สิ่งเหล่านี้ทำงานเหมือนกับ Bearer tokens หรือเฮดเดอร์ API key มาตรฐาน ซึ่ง Apidog จัดการได้โดยกำเนิด

JWT พร้อม claims ของอุปกรณ์

แพลตฟอร์มบางแห่งออก JWT ที่มี claims เฉพาะอุปกรณ์ (ID อุปกรณ์, รุ่น, เวอร์ชันเฟิร์มแวร์) การยืนยันตัวตนแบบ JWT Bearer มาตรฐานใช้งานได้ที่นี่ สคริปต์ก่อนคำขอสามารถจัดการการรีเฟรชโทเค็นได้หากโทเค็นมีอายุสั้น

การยืนยันตัวตนด้วยเฮดเดอร์แบบกำหนดเอง

แพลตฟอร์ม IoT ที่เป็นกรรมสิทธิ์บางแห่งใช้เฮดเดอร์การยืนยันตัวตนที่ไม่ใช่มาตรฐาน Apidog รองรับเฮดเดอร์แบบกำหนดเองใดๆ ก็ได้ ดังนั้นเฮดเดอร์การยืนยันตัวตนเฉพาะแพลตฟอร์ม เช่น X-Device-Token หรือ X-Device-Serial จึงใช้งานได้ง่าย

การทดสอบ IoT REST APIs ด้วย Apidog

นี่คือจุดที่ Apidog มอบคุณค่าที่แท้จริงสำหรับการพัฒนาแบ็กเอนด์ IoT

ขั้นตอนการจัดเตรียมอุปกรณ์

การจัดเตรียมอุปกรณ์ IoT มักจะเป็นขั้นตอน REST แบบหลายขั้นตอน:

1. ร้องขอการลงทะเบียนอุปกรณ์ (POST พร้อมหมายเลขซีเรียลอุปกรณ์, รุ่น, เวอร์ชันเฟิร์มแวร์)
2. รับ ID อุปกรณ์และข้อมูลประจำตัวในคำตอบ
3. กำหนดค่าอุปกรณ์ด้วยข้อมูลประจำตัวที่ได้รับ
4. ยืนยันสถานะการลงทะเบียน (GET สถานะอุปกรณ์)

การสนับสนุนการส่งคำขอแบบต่อเนื่องของ Apidog ทำให้สามารถทดสอบแบบ end-to-end ได้ สคริปต์หลังการส่งคำขอในขั้นตอนที่ 1 จะดึง ID อุปกรณ์และจัดเก็บเป็นตัวแปรสภาพแวดล้อม ขั้นตอนที่ 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) และยืนยันว่าการตอบสนองเป็นรูปแบบไบนารีที่คาดหวัง

การนำเข้าข้อมูล telemetry ผ่าน HTTP

หลายแพลตฟอร์มยอมรับข้อมูล telemetry ผ่าน HTTP POST เพย์โหลดอาจเป็น JSON แต่บ่อยครั้งขึ้นเรื่อยๆ ที่เป็นไบนารี (Protocol Buffers, MessagePack) เพื่อประสิทธิภาพของแบนด์วิธ

ในการทดสอบการนำเข้าข้อมูล telemetry แบบไบนารีด้วย Apidog:

1. ตั้งค่าประเภทเนื้อหาคำขอเป็น raw
2. เลือก binary เป็นรูปแบบเนื้อหา
3. วางเพย์โหลดที่เข้ารหัสแบบ hex หรือ base64 ของคุณ
4. ตั้งค่า Content-Type: application/octet-stream (หรือประเภทที่แพลตฟอร์มของคุณคาดหวัง)
5. ส่งและตรวจสอบคำตอบ

สำหรับเพย์โหลด protobuf โดยเฉพาะ คุณจะต้องเข้ารหัสเพย์โหลดทดสอบของคุณโดยใช้ไลบรารี protobuf ก่อนที่จะนำไปวางใน Apidog เครื่องมือนี้ไม่มีการเข้ารหัส protobuf ในตัว แต่สามารถจัดการการขนส่งได้อย่างถูกต้อง

การทดสอบด้วยใบรับรอง SSL แบบกำหนดเอง

แบ็กเอนด์ IoT มักจะทำงานบนเครือข่ายส่วนตัวที่มีใบรับรองแบบ self-signed หรือใช้ certificate pinning การตั้งค่า SSL ของ Apidog ช่วยให้คุณสามารถ:

• ปิดใช้งานการยืนยัน SSL สำหรับการพัฒนาในเครื่อง (ใบรับรองแบบ self-signed บนเซิร์ฟเวอร์ dev)
• โหลดใบรับรอง CA แบบกำหนดเองสำหรับการตรวจสอบ CA ส่วนตัว
• โหลดใบรับรองไคลเอนต์สำหรับการทดสอบ mTLS

สำหรับสภาพแวดล้อมการพัฒนาที่มีใบรับรองแบบ self-signed การปิดใช้งานการยืนยัน SSL จะช่วยให้คุณทำงานต่อได้ทันที สำหรับการทดสอบการผลิต ให้โหลดใบรับรอง CA ของคุณเพื่อตรวจสอบใบรับรองของเซิร์ฟเวอร์ได้อย่างถูกต้อง

การทดสอบ WebSocket สำหรับสตรีมอุปกรณ์ IoT

แพลตฟอร์ม IoT มีการนำเสนอเอนด์พอยต์ WebSocket มากขึ้นเรื่อยๆ สำหรับการสื่อสารอุปกรณ์แบบเรียลไทม์ กรณีการใช้งานทั่วไป:

สตรีมเงาอุปกรณ์ / อุปกรณ์คู่: แพลตฟอร์มบางแห่ง (AWS IoT, Azure IoT) มีเอนด์พอยต์ WebSocket ที่สตรีมการอัปเดตเงาอุปกรณ์ เมื่ออุปกรณ์รายงานสถานะ คลาวด์จะสะท้อนสถานะนั้นผ่านการเชื่อมต่อ WebSocket ไปยังไคลเอนต์ที่สมัครสมาชิก

สตรีมข้อมูล telemetry แบบสด: แดชบอร์ดแสดงข้อมูลเซ็นเซอร์แบบเรียลไทม์เชื่อมต่อผ่าน WebSocket ไปยังเอนด์พอยต์สตรีมข้อมูล telemetry

การส่งคำสั่ง: แพลตฟอร์มบางแห่งส่งคำสั่งแบบเรียลไทม์ไปยังอุปกรณ์ออนไลน์ผ่าน WebSocket แทนที่จะรอให้อุปกรณ์พอลลิ่ง

การทดสอบสิ่งเหล่านี้ด้วยไคลเอนต์ WebSocket ของ Apidog:

1. เชื่อมต่อกับ URL WebSocket พร้อมเฮดเดอร์การยืนยันตัวตนที่จำเป็น (โดยปกติคือ Bearer token หรือ API key)
2. ส่งข้อความการสมัครสมาชิกหากโปรโตคอลกำหนด (เช่น สมัครรับสตรีมเหตุการณ์ของอุปกรณ์)
3. สังเกตสตรีมข้อความขาเข้าในบันทึกข้อความ
4. ส่งข้อความคำสั่งทดสอบและตรวจสอบพฤติกรรมฝั่งอุปกรณ์

สำหรับแพลตฟอร์มที่ใช้ subprotocols (เฮดเดอร์ Sec-WebSocket-Protocol) Apidog รองรับการระบุ subprotocols ในการกำหนดค่าการเชื่อมต่อ

สิ่งที่จะใช้สำหรับการทดสอบ MQTT

เนื่องจาก Apidog ไม่รองรับ MQTT นี่คือการตั้งค่าการทดสอบ MQTT ที่เป็นประโยชน์:

MQTTX เป็นไคลเอนต์ MQTT ทั่วไปที่มีความสามารถมากที่สุด มี GUI บนเดสก์ท็อป, รองรับ MQTT โปรโตคอลทุกเวอร์ชัน (3.1.1 และ 5.0), จัดการการเชื่อมต่อ TLS/mTLS, และมีโหมดการเขียนสคริปต์สำหรับลำดับข้อความอัตโนมัติ สำหรับการทดสอบ MQTT แบบโต้ตอบ MQTTX เป็นจุดเริ่มต้นที่ดีที่สุด

MQTT Explorer ใช้งานง่ายกว่าและยอดเยี่ยมสำหรับการเรียกดูโครงสร้างหัวข้อด้วยสายตา หากความต้องการหลักของคุณคือการทำความเข้าใจว่าข้อความใดกำลังไหลผ่านโบรกเกอร์ MQTT Explorer จะทำให้มองเห็นได้ชัดเจน

เครื่องมือ CLI ของ mosquitto (mosquitto_pub, mosquitto_sub) มีอยู่ในเครื่องมือพัฒนาส่วนใหญ่ (ผ่านตัวจัดการแพ็กเกจ) และทำงานได้ดีสำหรับการทดสอบด้วยสคริปต์อย่างรวดเร็ว หากคุณต้องการส่งข้อมูลทดสอบไปยังหัวข้อ MQTT หรือสมัครรับและบันทึกข้อความขาเข้า เครื่องมือ CLI มักจะเร็วกว่า GUI

สำหรับการรวม CI/CD, การเขียนโค้ดทดสอบแบบกำหนดเองโดยใช้ไลบรารี MQTT ที่เป็นภาษาแม่ (paho-mqtt สำหรับ Python, MQTT.js สำหรับ Node) เป็นแนวทางที่ยืดหยุ่นที่สุด

การตั้งค่าการทดสอบแบ็กเอนด์ IoT ที่ใช้งานได้จริง

โครงสร้างสภาพแวดล้อม 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/ – ข้อมูลประจำตัวไม่ถูกต้อง, โทเค็นหมดอายุ, เพย์โหลดที่ผิดรูปแบบ

รายการตรวจสอบการทดสอบเพย์โหลดแบบไบนารี:

• ทดสอบด้วยเพย์โหลดไบนารีที่ถูกต้อง (happy path)
• ทดสอบด้วยเพย์โหลดไบนารีที่ถูกตัดทอน (ข้อความไม่สมบูรณ์)
• ทดสอบด้วยเฮดเดอร์ Content-Type ที่ไม่ถูกต้อง
• ทดสอบขนาดเพย์โหลดตามขนาดสูงสุดที่ระบุไว้ในเอกสารของแพลตฟอร์มของคุณ
• ทดสอบด้วยการยืนยันตัวตนของอุปกรณ์ที่ถูกต้องและไม่ถูกต้อง

คำถามที่พบบ่อย

Apidog รองรับการทดสอบ MQTT หรือไม่?
ไม่ Apidog ไม่มีการรองรับ MQTT โดยกำเนิด สำหรับการทดสอบ MQTT ให้ใช้ MQTTX, MQTT Explorer หรือเครื่องมือ CLI ของ mosquitto Apidog ครอบคลุมเลเยอร์ HTTP และ WebSocket ของแบ็กเอนด์ IoT ของคุณ ไม่ใช่เลเยอร์โบรกเกอร์ MQTT

Apidog สามารถทดสอบเอนด์พอยต์ CoAP ได้หรือไม่?
ไม่ CoAP ทำงานบน UDP ซึ่ง Apidog ไม่รองรับ สำหรับการทดสอบ CoAP ให้ใช้ copper4cr หรือ libcoap

ฉันจะทดสอบเพย์โหลด protobuf แบบไบนารีใน Apidog ได้อย่างไร?
เข้ารหัสข้อความ protobuf ของคุณเป็นไบนารีโดยใช้ไลบรารี protobuf ของภาษาของคุณ จากนั้นแปลงเป็น hex หรือ base64 ใน Apidog ให้ตั้งค่าเนื้อหาเป็น raw binary และวางเพย์โหลดที่เข้ารหัส ตั้งค่า Content-Type เป็น application/protobuf หรือตามที่แพลตฟอร์มของคุณคาดหวัง

Apidog รองรับ mTLS สำหรับการยืนยันตัวตนด้วยใบรับรองอุปกรณ์หรือไม่?
ใช่ การตั้งค่า SSL ของ Apidog ช่วยให้คุณสามารถโหลดใบรับรองไคลเอนต์และคีย์ส่วนตัวสำหรับการเชื่อมต่อ mTLS ซึ่งครอบคลุมการทดสอบเอนด์พอยต์ที่ต้องใช้การยืนยันตัวตนด้วยใบรับรองอุปกรณ์

เราสามารถใช้ Apidog เพื่อทดสอบ AWS IoT Core, Azure IoT Hub หรือ Google Cloud IoT ได้หรือไม่?
ใช่ สำหรับ HTTP REST API ของแพลตฟอร์มเหล่านี้ AWS IoT Core มี REST management API, Azure IoT Hub มีเอนด์พอยต์ REST สำหรับการจัดการอุปกรณ์และการเรียกใช้เมธอดโดยตรง และ Google Cloud IoT Core มี REST API ทั้งหมดนี้สามารถทดสอบได้ด้วย Apidog การเชื่อมต่อ MQTT ไปยังแพลตฟอร์มเหล่านี้ต้องใช้ MQTTX หรือเครื่องมือที่คล้ายกัน

แนวทางที่ดีที่สุดสำหรับการทดสอบการเข้ารหัส telemetry แบบไบนารีที่มีแบนด์วิธต่ำคืออะไร?
สร้าง test fixtures ของเพย์โหลดไบนารีที่รู้จัก (ถูกต้อง, ถูกตัดทอน, ผิดรูปแบบ) โดยใช้ไลบรารีการเข้ารหัสของคุณ จัดเก็บสิ่งเหล่านี้เป็นตัวแปรสภาพแวดล้อมหรือไฟล์ทดสอบ ใช้ Apidog เพื่อส่งไปยังเอนด์พอยต์การนำเข้าของคุณและตรวจสอบรหัสการตอบสนองและพฤติกรรมการประมวลผล

การพัฒนาแบ็กเอนด์ IoT ครอบคลุมโปรโตคอลที่ไม่มีเครื่องมือเดียวใดครอบคลุมได้อย่างสมบูรณ์ คำตอบที่ตรงไปตรงมาคือคุณต้องมีเครื่องมืออย่างน้อยสองอย่าง: อย่างหนึ่งสำหรับการทดสอบ MQTT และอีกอย่างสำหรับการทดสอบ REST/WebSocket Apidog จัดการกับเลเยอร์ HTTP ได้อย่างครอบคลุม – การจัดเตรียม, การจัดการ, การนำเข้าข้อมูล telemetry, เพย์โหลดไบนารี, mTLS, และสตรีม WebSocket สำหรับ MQTT นั้น MQTTX หรือ mosquitto จะเข้ามาเติมเต็มส่วนที่ขาดหาย การรู้ว่าควรเลือกใช้เครื่องมือใดเมื่อใด มีประโยชน์มากกว่าการแกล้งทำเป็นว่าเครื่องมือเดียวครอบคลุมทุกอย่าง