โครงสร้าง response มี field เพิ่ม: เขียน parser ให้รองรับ

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

การเพิ่ม field ที่ไม่เกี่ยวข้องไม่ควรทำให้ระบบล้ม แต่ความยืดหยุ่นก็ไม่ควรปล่อยให้ข้อมูลเงินที่จำเป็นผิดชนิดผ่านไปได้

RFC 8259 แยก string, number และ null เป็นคนละชนิด การ parse ได้จึงไม่แปลว่าชนิดข้อมูลตรงสัญญาธุรกิจ

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

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

• ตรวจเฉพาะ field ที่ต้องใช้พร้อมชนิดและเงื่อนไข
• อนุญาต field เพิ่มที่ไม่เปลี่ยนการตัดสิน แต่ไม่ใช้มันจนตรวจสัญญา
• เพิ่ม test สำหรับ extra field, missing required และ wrong type แยกกัน

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

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

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

เงินตอบกลับ MeeTang อาจเป็น string ของเลขฐานสิบ จึงต้องยอมรับชนิดที่สัญญาระบุ ไม่เคร่งจนปฏิเสธข้อมูลถูกต้องหรือกว้างจนรับทุกข้อความ

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

อ่าน API Docs และเทียบ response ที่ตัดข้อมูลลับจาก API Logs กับชุดทดสอบของ client

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

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

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

• RFC 8259: JSON — ชนิด string, number, null และข้อจำกัดความแม่นยำในการรับส่ง JSON

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