ทศนิยมใน JSON: ออกแบบการตรวจยอดก่อนส่ง

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

JSON number ไม่รับรองว่าภาษาฝั่งรับใช้เลขฐานสิบ การคำนวณเงินด้วย binary floating point แล้วเทียบเท่ากันตรง ๆ อาจสร้างผลต่างเล็กที่ตรวจยาก

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

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

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

• ใช้ decimal หรือหน่วยย่อยจำนวนเต็มในการคำนวณภายในตามสกุลเงิน
• กำหนดจุดปัดเศษก่อน serialize ให้ตรง field ที่ API รับ
• ตรวจยอดรวมหลัง parse response ซึ่งอาจส่งเงินกลับเป็น string

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

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

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

อย่าเปลี่ยน amount เป็น string ทุก endpoint เอง เพราะ request schema อาจต้องการ number และอย่าปัดทีละขั้นโดยไม่ตกลงกติกาให้ชัด

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

เทียบชนิด request/response ใน API Docs แล้วดูรายการผลลัพธ์ใน Transactions

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

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

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

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

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