ตรวจ Content-Type เมื่อ API ไม่อ่าน payload

1. ระบุปัญหาของสัญญาข้อมูล

body หน้าตาเหมือน JSON ในโค้ดอาจถูกส่งเป็น form หรือข้อความซ้อน JSON ต้องตรวจ bytes และ header ที่ส่งจริงก่อนแก้ endpoint

RFC 9110 นิยามความหมายของ HTTP แต่ผลธุรกิจยังต้องอ่านจาก body ตามสัญญา MeeTang อย่าตัดสินจากสถานะการเชื่อมต่ออย่างเดียว

2. ขั้นตอนตรวจฝั่ง integration

ทำงานนี้ใน backend หรือชุดทดสอบของร้าน แยกข้อมูลจำลองจากระบบจริง และไม่เพิ่มสิทธิ์เกินงานเพื่อให้ test ผ่าน

• serialize object เพียงครั้งเดียวด้วย JSON library
• ตั้ง Content-Type: application/json และ Accept: application/json
• ตรวจ request ในการทดสอบโดยแทน key และข้อมูลจริงก่อนเก็บหลักฐาน

3. ตัวอย่างจำลองและผลที่ควรตรวจ

ตัวระบุ ยอด และเหตุการณ์ต่อไปเป็นตัวอย่าง ไม่ใช่ credentials หรือข้อมูลบัญชีที่นำไปใช้จริงได้

4. สิ่งที่ห้ามอนุมานเพิ่ม

Payment bank-slip รับ qr_payload ซึ่งเป็นข้อความ QR ไม่ใช่ภาพ base64 แม้ตั้ง Content-Type ถูกก็ไม่ทำให้ field ผิดกลายเป็นถูก

5. จุดตรวจใน MeeTang

เทียบตัวอย่างใน API Docs หรือ Payment Docs และตรวจ HTTP/body ที่ API Logs แสดงอย่างจำกัดข้อมูล

พฤติกรรมผลิตภัณฑ์ในบทความตรวจจากสัญญาและ source ของ repository วันที่ 27 กันยายน 2026 ไม่ใช่ผลทดสอบ deployment จริง จึงต้องตรวจสัญญาที่ใช้งานก่อนเปิดส่งข้อมูล

แหล่งอ้างอิงและขอบเขตเนื้อหา

แหล่งต่อไปนี้อธิบายหลักการทั่วไป ส่วนขั้นตอนของ MeeTang ตรวจจากฟีเจอร์ในระบบ ณ วันที่อัปเดต ตัวเลขในตัวอย่างไม่ใช่ข้อมูลผู้ใช้งานจริง

• RFC 9110: HTTP Semantics — ความหมาย HTTP method, status, representation และ idempotency

จัดทำด้วย AI ช่วยเรียบเรียงและตรวจเทียบกับโค้ด ไม่ใช่คำแนะนำภาษีหรือการรับรองผลทางบัญชี เงื่อนไขฟีเจอร์และโควตาขึ้นกับแพ็กเกจและสิทธิ์ที่ได้รับ