สาระสำคัญในการออกแบบ data contract ของ JSON API
มีหกสิ่งที่เปลี่ยนแปลงได้ยากมากเมื่อปล่อยไปแล้ว: response envelope, รูปแบบ error, รูปร่างของ pagination, การแทน ID และเวลา, ความหมายของ null เทียบกับฟิลด์ที่ไม่มีอยู่ และการวิวัฒน์เวอร์ชัน
การนำ JSON ไปใช้ในระบบจริง: วิธีกำหนด API contract วิธีจัดการคอนฟิกและ fixture วิธีรับมือความเข้ากันได้ของเวอร์ชัน และวิธีดูแลข้อมูลทดสอบ
5 บทความมีหกสิ่งที่เปลี่ยนแปลงได้ยากมากเมื่อปล่อยไปแล้ว: response envelope, รูปแบบ error, รูปร่างของ pagination, การแทน ID และเวลา, ความหมายของ null เทียบกับฟิลด์ที่ไม่มีอยู่ และการวิวัฒน์เวอร์ชัน
คอนฟิกต้องถูกแบ่งชั้นและตรวจสอบ; fixture ต้องแน่นอน อ่านง่าย และ diff ได้ หากไฟล์สองชนิดนี้ถูกจัดการไม่ดี ต้นทุนการวินิจฉัยปัญหาจะสูงไปอีกนาน
ห้าสิบเรกคอร์ดกลายเป็นห้าสิบเอ็ดและ diff รายงานการเปลี่ยนแปลงห้าสิบเอ็ดครั้ง ครอบคลุม false positive ของ text diff, การจับคู่อาร์เรย์ด้วย id, การ normalize ด้วย jq และ patch ที่ใช้งานได้
merge=union ปล่อย JSON ที่พังผ่านไปและยังรายงานว่าสำเร็จ บทความนี้ไล่ดู three-way merge driver ที่เข้าใจคีย์สำหรับ JSON พร้อมนิสัยสามข้อที่ลด conflict
การเพิ่มฟิลด์ไม่ปลอดภัยโดยอัตโนมัติ ครอบคลุมขอบเขตความเข้ากันได้ ฟิลด์เวอร์ชัน ช่วงเวลาการเลิกใช้ การย้ายข้อมูลแบบเขียนคู่ contract test และตัวชี้วัด canary