การตรวจสอบ API

ทำไม API ต้องการการมอนิเตอร์ของตัวเอง

API ไม่ใช่แค่หน้าเว็บที่อยู่ภายใต้ /api/ แต่มันคือสัญญา วิธี HTTP มีความสำคัญ - GET กับ POST เปลี่ยนความหมาย เฮดเดอร์มีข้อมูลการยืนยันตัวตน, content negotiation, คีย์ idempotency เนื้อหาใน request คืออินพุต โค้ดตอบกลับสำคัญ (401 vs 403 vs 422 - แต่ละค่าบอกสถานการณ์ต่างกัน) เนื้อหา response มีโครงสร้าง - JSON path ที่ผู้ใช้งาน integration ต้องพึ่งพา การตรวจ uptime แบบทั่วไปที่ยิงแค่ URL ด้วย GET จะพลาดปัญหาส่วนใหญ่ที่ทำให้ API ล่ม: JSON ที่ผิดแต่ตอบ 200, endpoint ยืนยันตัวตนที่รับข้อมูลผิด, webhook ที่ payload ผิด, endpoint ที่ตอบ 200 แต่เนื้อหา "status": "error" ภายใน

การมอนิเตอร์ API แก้ปัญหาเหล่านี้ได้ โดยให้คุณควบคุมทุกส่วนของ request และการตรวจสอบ response คุณสามารถตั้งค่าการเรียก API แบบเดียวกับที่ integrator ใช้ — method เดียวกัน, header เดียวกัน, body เดียวกัน, auth เดียวกัน — พร้อมกำหนดนิยามความสำเร็จได้เอง เช่น โค้ดที่ต้องได้, ค่าใน JSON path, ขีดเวลาในการตอบกลับ, ขนาดข้อมูลสูงสุด

การตั้งค่า request

สำหรับ monitor API แต่ละตัวใน DiagnoSEO Uptime Monitoring คุณสามารถตั้งค่าได้ดังนี้:

• วิธี HTTP: GET, POST, PUT, PATCH, DELETE, HEAD เลือกแบบที่ integrator ใช้
• Custom header: ในรูปแบบ JSON เช่น {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"} มาตรฐานสำหรับทดสอบ OAuth, JWT, API key, content negotiation
• Body ของ request: string ใดก็ได้ — JSON, XML, form-encoded, plain text ส่งเมื่อใช้ POST/PUT/PATCH/DELETE
• Basic auth: กรอกผู้ใช้และรหัสผ่านถ้า endpoint มีการป้องกันด้วยวิธีนี้
• โค้ดสถานะที่ต้องการ: เป็นลิสต์หรือช่วงค่า ค่าปกติคือ 200-399 แต่คุณสามารถกำหนดเจาะจง เช่นเพียง 201 สำหรับ endpoint สร้างใหม่ หรือหลายค่า (เช่น 200,202,204).

การตรวจสอบจะตาม redirect สูงสุด 5 ครั้ง, ถอดรหัส gzip, แยก Content-Type เพื่อจับ JSON ทุกครั้งที่เช็คจะบันทึกโค้ดจริง, เวลาในการตอบกลับ, ขนาด และข้อผิดพลาด (ถ้ามี) หลายเหตุการณ์ fail ติดต่อกัน (ตั้งค่าได้ ปกติ 2) จะสร้าง incident

Asercje JSON path

โค้ดสถานะอย่างเดียวไม่พอสำหรับหลายๆ API endpoint health อาจจะตอบ 200 พร้อมข้อมูล {"status": "degraded", "db": "down"} — ยังเป็น 200 แต่อยากรู้แน่นอน API ราคาตอบ 200 แต่ data.price เป็น null API ค้นหาอาจตอบ 200 แต่ results: [] เพราะ index ล่ม

กรณีแบบนี้ตั้งค่า asercja JSON path กำหนด path (เช่น data.status หรือ health.checks.db) และค่าที่คาดหวัง (เช่น healthy, true หรือค่าตัวเลขที่ต้องการ) ทุกครั้งที่เช็ค Response จะถูกแปลง JSON แล้วเปรียบเทียบค่าตาม path ไม่ตรงกันถือว่า fail ไม่สนใจ HTTP status

ไวยากรณ์ path จะใช้จุดหรือวงเล็บ data.items[0].id ใช้ได้ หรือ users.john.email ก็ได้ ค่าที่ assert เปรียบเทียบแบบ string เช่น "true" ตรงกับ bool true และค่าตัวเลขเทียบได้ทั้ง string และตัวเลข

แพทเทิร์นการยืนยันตัวตน

2 วิธี auth ที่พบบ่อยรองรับในระบบแล้ว สำหรับ Bearer token (OAuth, JWT, API key) ให้ใส่ใน headers: {"Authorization": "Bearer eyJhbGciOi..."} Token จะอยู่ใน config monitor และส่งทุกครั้งที่เช็ค สำหรับ basic auth มีช่อง user/password แยกเฉพาะ ซึ่งรวมเป็น header ให้เองอัตโนมัติ

ถ้า auth ต้อง sign ทุก request หรือ refresh token บ่อย จะยากขึ้น สองแนวทาง: (1) สร้าง token อายุยาวสำหรับระบบ monitor โดยเฉพาะ หรือ (2) ทำ endpoint health ที่ไม่ต้องยืนยันตัวตนซึ่งสะท้อนสถานะ endpoint ที่แท้จริงแล้ว monitor ที่นั่น API สมัยใหม่ส่วนมากรองรับข้อ 2 อยู่แล้ว

รูปแบบที่เราแนะนำ

• มี monitor สำคัญต่อ endpoint หลักเท่านั้น ไม่ต้องเช็คทุก endpoint — เลือกสัก 5-10 อันที่ล่มแล้วกระทบธุรกิจจริง
• ใช้โค้ดที่แม่นยำ ค่า default 200-399 กว้างเกินไปสำหรับ API Endpoint สร้างใหม่ควรตอบ 201; แบบ idempotent ให้ตอบ 200; login ตอบ 200 (สำเร็จ) หรือ 401 (fail แบบถูกต้อง — ไม่ใช่ 500)
• ผสาน status กับ assertion JSON ทั้งสองช่วยจับ regression ด้าน transport และเนื้อหาเพจ เฉพาะ status ไม่พอจับ error ที่ content; assertion JSON อย่างเดียวเปราะเวลา redirect
• ตั้งขีดเวลา response API degradation เป็นสัญญาณ early ของปัญหา dependency Monitor ที่ตั้ง rt_threshold_ms = 800 จะเตือนให้เห็นว่า API ช้าก่อนที่มันจะล่มจริง
• ส่ง body ขนาดเล็ก Checks วิ่งทุกนาที — body ใหญ่เปลือง bandwidth ทั้งสองฝั่ง Payload ที่เป็นตัวแทนแต่เล็กพอเพียงก็ได้

ผสานกับ monitor ประเภทอื่น

สำหรับทุก endpoint ของ API, monitor API เช็คว่าการเรียกทำงานได้จริง Monitor ping หรือ port แยกเช็คว่า host ยังออนไลน์ การตรวจ SSL/โดเมน ในชื่อ host เดียวกัน จับปัญหาใบรับรอง/การลงทะเบียน Sub-monitor DNS คอยระวัง record ที่เปลี่ยนและเสี่ยงโดน spoof รวมแล้ว 4 แบบ monitor ต่อ API ครบวงจรโดยแทบไม่เหลื่อมซ้อนกัน

วิธีตั้งค่า

เปิดเครื่องมือ คลิก "เพิ่ม monitor" เลือกประเภท "API" วาง URL เปิดส่วนขั้นสูง เลือกวิธี, ใส่ header ตาม JSON, วาง body ถ้าต้องใช้, ใส่ basic auth ถ้ามี, พิมพ์โค้ดที่คาดหวัง (เช่น 200 หรือ 200,201) เพิ่ม assertion JSON path ถ้ามี ตั้งช่วงเวลาและคอนเฟิร์ม threshold บันทึกข้อมูล Cycle ถัดไป monitor จะยิง API ของคุณเหมือน integrator, เช็คผลลัพธ์และแจ้งเตือนเมื่อ regression เกิดขึ้นทันที

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

• สามารถใช้วิธี HTTP อะไรได้บ้างเพื่อตรวจสอบ API?

  GET, POST, PUT, DELETE, PATCH และ HEAD คุณสามารถเลือกวิธีให้แต่ละ monitor — endpoint แบบเขียนข้อมูล (POST/PUT/PATCH) ก็สามารถตั้งค่า body ของ request เป็น JSON string หรือ form data ได้ด้วย

• Assertion JSON ทำงานอย่างไร?

  คุณใส่ JSON path (เช่น data.status หรือ results[0].id) กับค่าที่ต้องการ Monitor จะอ่าน response, แปลงเป็น JSON, ดึงค่าตาม path แล้วเทียบกับที่ต้องการ ถ้าไม่ตรง check จะ fail พร้อมโชว์ actual value ในข้อความ "assertion failed"

• สามารถกำหนด custom header สำหรับยืนยันตัวตนได้หรือไม่?

  ได้ header HTTP แบบ custom สามารถตั้งค่าต่างหากให้แต่ละ monitor — Authorization, API key, content-type ฯลฯ ค่าที่ใส่ header จะถูกเข้ารหัสในฐานข้อมูลเสมอ ส่วน Basic Auth มีช่อง username/password แยกที่ระบบจะสร้าง header ให้อัตโนมัติ

• ถ้า API ตอบ 200 แต่เนื้อหามี error จะทำอย่างไร?

  ตัวอย่างที่พบบ่อย: API ตอบ HTTP 200 แต่ body แจ้ง {"status":"error"} monitor uptime แบบพื้นฐานจะเข้าใจว่า system ปกติ ใช้ JSON assertion status == "ok" เพื่อจับกรณีนี้ — assertion จะ fail และ monitor แจ้ง DOWN ถึงแม้ HTTP จะตอบ 200

• ทำอย่างไรถ้า API ของฉันถูกจำกัด rate?

  ตั้ง interval ของ check ให้ไม่เกินข้อจำกัด API (เช่น ทุก 5 นาทีหาก API จำกัดที่ 12 call/ชม.) Monitor จะนับ 1 API call ต่อ 1 check จาก region เดียว เช็คแบบ multi-region จะคูณจำนวน call — ถ้า API จำกัดมากให้ใช้ single-region