เครื่องมือสำหรับนักพัฒนา · JSON ฟอร์แมตเตอร์ & เครื่องมือตรวจสอบความถูกต้อง
วิธีที่ JSON แทนที่ XML เป็นรูปแบบเริ่มต้นสำหรับ web API
· พื้นหลัง
json มาตรฐาน การตรวจสอบ
เมื่อยี่สิบปีที่แล้ว XML เป็นรูปแบบสันนิษฐานสำหรับทุกสิ่งที่ส่งระหว่างระบบ โพสต์นี้จะติดตามวิธีที่ JSON แทนที่มันใน API ของเว็บ แต่ละรูปแบบได้รับการออกแบบมาเพื่ออะไร และเหตุใด XML จึงยังคงครอบงำบางโดเมน
เหลือปลายทาง SOAP หนึ่งจุด
เหลือจุดสิ้นสุด SOAP หนึ่งจุด นั่นคือการบูรณาการที่พูด XML ในโค้ดเบสที่ทุกอย่างพูด JSON และคำถามว่าเรามาถึงจุดนี้ได้อย่างไร ความแตกต่างมักปรากฏในโค้ดไคลเอ็นต์: เส้นทางหนึ่งจัดการซองจดหมาย เนมสเปซ และประเภทที่สร้างขึ้น ในขณะที่จุดสิ้นสุดที่ใหม่กว่าจะแลกเปลี่ยนออบเจ็กต์ธรรมดาผ่านไลบรารี HTTP แบบไลท์เวท การสังเกตนั้นอธิบายถึงสถาปัตยกรรมท้องถิ่น ไม่ใช่ลำดับเหตุการณ์สากล
ฟอร์แมตเตอร์รองรับ JSON เท่านั้น การแปลงข้ามรูปแบบเป็นของแผงตัวแปลงไวยากรณ์แยกต่างหาก ความนิยมของ JSON ไม่ได้ทำให้ XML ล้าสมัย และการพิมพ์สวยๆ ในท้องถิ่นก็ไม่ช่วยยืนยันสัญญา API บทความนี้จะแยกแยะความแตกต่างระหว่างการยอมรับในอดีตจากพฤติกรรมที่แคบกว่าที่นำมาใช้ในเส้นทางนี้ การเรียกร้องในอดีตที่ไม่ได้รับการสนับสนุนเกี่ยวกับวันที่ชี้ขาด สาเหตุ หรือการเปลี่ยนทดแทนทั่วทั้งตลาดจะถูกละเว้นหรือแก้ไขโดยเจตนา แทนที่จะอนุมานจากการผิดนัดชำระหนี้ในปัจจุบัน
XML ถูกสร้างขึ้นเพื่ออะไร
XML ถูกสร้างขึ้นมาเพื่ออะไร — เอกสารที่มีเนื้อหาผสม เนมสเปซ สคีมา และไปป์ไลน์การเปลี่ยนแปลง องค์ประกอบสามารถมีทั้งข้อความและมาร์กอัปย่อย แอตทริบิวต์สามารถนำข้อมูลเมตาได้ และชื่อที่ผ่านการรับรองเนมสเปซเพื่อให้คำศัพท์อยู่ร่วมกันได้ เทคโนโลยีเช่น XML Schema, XPath และ XSLT สนับสนุนการตรวจสอบ การสืบค้น และการแปลงทั่วทั้งเวิร์กโฟลว์ที่เน้นเอกสารเป็นศูนย์กลาง
ความสามารถเหล่านั้นไม่ได้ไร้ประโยชน์เมื่อเพย์โหลดเป็นสิ่งพิมพ์ เอกสารทางธุรกิจที่ลงนาม หรือข้อความทางอุตสาหกรรมที่สามารถขยายได้ พวกเขากำหนดแนวคิดมากกว่าการแลกเปลี่ยนอ็อบเจ็กต์และอาเรย์แบบธรรมดาที่ต้องการ การเปรียบเทียบตัวอย่างที่เทียบเท่ากันจึงควรพิจารณาสัญญา ไม่ใช่เพียงการนับอักขระเท่านั้น: XML และ JSON เปิดเผยเครื่องมือการสร้างแบบจำลองที่แตกต่างกัน และไม่มีไวยากรณ์ใดที่ให้ความหมายโดเมนที่ถูกต้องโดยอัตโนมัติ
สิ่งที่เบราว์เซอร์สามารถทำได้โดยกำเนิด
สิ่งที่เบราว์เซอร์สามารถทำได้โดยกำเนิด — XMLHttpRequest สามารถดึงข้อมูลรูปแบบข้อความใดก็ได้ และเบราว์เซอร์เสนอการแยกวิเคราะห์ XML DOM โค้ด JavaScript ช่วงต้นบางครั้งได้รับการประเมินข้อความที่มีลักษณะคล้าย JSON ซึ่งเป็นแนวทางปฏิบัติที่ไม่ปลอดภัยเมื่ออินพุตไม่น่าเชื่อถือ มาตรฐาน `JSON.parse` ภายหลังได้จัดเตรียมตัวแยกวิเคราะห์เฉพาะ แยกวิเคราะห์ JSON แมปอย่างเป็นธรรมชาติกับ JavaScript อาร์เรย์ วัตถุ สตริง ตัวเลข บูลีน และ null
การแมปนั้นลดพิธีการสำหรับแอปพลิเคชันเบราว์เซอร์จำนวนมาก แต่ไม่มีหลักฐานว่าเบราว์เซอร์ไม่สามารถประมวลผล XML หรือ API เดียวเท่านั้นที่กำหนดการนำไปใช้ XML DOM จะรักษาองค์ประกอบ คุณลักษณะ และเนมสเปซ แทนที่จะกลายเป็นวัตถุธรรมดาโดยอัตโนมัติ การกล่าวอ้างในอดีตเกี่ยวกับสาเหตุจำเป็นต้องมีแหล่งที่มานอกเหนือจากความสะดวกในการใช้งาน ดังนั้นเวอร์ชันที่ไม่รองรับจึงถูกละเว้นหรือแก้ไขที่นี่
จุดเปลี่ยน — API เว็บสาธารณะที่นำเสนอ JSON ควบคู่ไปกับ XML จากนั้น JSON เท่านั้น และ REST แทนที่ SOAP สำหรับบริการใหม่ส่วนใหญ่
จุดเปลี่ยน — API เว็บสาธารณะจำนวนมากเปิดเผย JSON ควบคู่ไปกับ XML และบริการต่อมาจำนวนมากเลือก JSON เป็นตัวแทนหลัก สไตล์ HTTP แบบน้ำหนักเบายังกลายเป็นเรื่องปกติสำหรับ API ของแอปพลิเคชัน ในขณะที่ SOAP ยังคงอยู่ในระบบนิเวศที่จัดตั้งขึ้น ส่วนแบ่งการตลาดที่แน่นอน การเคลื่อนย้ายครั้งแรก และวันที่แตกต่างกันไปตามแหล่งที่มา และไม่สามารถสร้างได้จากพื้นที่เก็บข้อมูลฟอร์แมตเตอร์นี้
ด้วยเหตุนี้ การกล่าวอ้างทางประวัติศาสตร์ที่ไม่ได้รับการสนับสนุนจึงถูกละเว้นหรือแก้ไข แทนที่จะแปลงเป็นเรื่องราวที่มีสาเหตุเดียวที่เป็นระเบียบเรียบร้อย กลไกการป้องกันคือแรงกดดันในการทำงานร่วมกัน: ไลบรารีไคลเอนต์ เอกสาร เครื่องมือ และบริการใกล้เคียงจะเสริมรูปแบบเมื่อทีมสร้างมาตรฐาน ข้อเสนอแนะดังกล่าวสามารถอธิบายค่าเริ่มต้นในเครื่องได้โดยไม่ต้องอ้างว่า XML หายไปหรือทุก REST API ใช้ JSON
ค่าใช้จ่ายของสวิตช์
ค่าใช้จ่ายของสวิตช์ — JSON ไม่มีความแตกต่างระหว่างแอตทริบิวต์และองค์ประกอบลูก ไม่มีโมเดลเนื้อหาแบบผสม และไม่มีไวยากรณ์ความคิดเห็น ไวยากรณ์ฐาน JSON ไม่ได้กำหนดสกีมาของแอปพลิเคชันด้วย ทีมที่ต้องการสัญญาจะเพิ่มระบบแยกต่างหาก เช่น JSON Schema หรือ OpenAPI โดยแต่ละทีมจะมีคำศัพท์ เครื่องมือ และการตัดสินใจด้านเวอร์ชันของตัวเอง
การแปลงจึงอาจสูญเสียข้อมูล เว้นแต่ว่าการแมปจะได้รับการออกแบบอย่างชัดเจน องค์ประกอบ XML ที่ซ้ำกันอาจกลายเป็นอาร์เรย์ ชื่อที่ผ่านการรับรองเนมสเปซจำเป็นต้องมีการแสดง และข้อความที่แทรกด้วยมาร์กอัปไม่สามารถกลายเป็นวัตถุธรรมดาได้อย่างหมดจดเสมอไป ไวยากรณ์เพย์โหลดที่เรียบง่ายขึ้นจะย้ายความซับซ้อนไปสู่สัญญาหรือแบบแผนภายนอก มันไม่ทำให้การตรวจสอบความถูกต้อง วิวัฒนาการ และเอกสารประกอบไม่จำเป็น
โดยที่ XML ยังคงชนะ
จุดที่ XML ยังคงชนะ — กระบวนการเผยแพร่เวิร์กโฟลว์จะได้รับประโยชน์จากเนื้อหาแบบผสมและคำศัพท์เกี่ยวกับเอกสารที่สร้างขึ้น ในขณะที่รูปแบบ Office บรรจุ XML ส่วนต่างๆ เพื่อแสดงถึงเอกสารที่มีเนื้อหาสมบูรณ์ มาตรฐานทางการเงินและการส่งข้อความระดับองค์กรที่สมบูรณ์อาจขึ้นอยู่กับเนมสเปซ สคีมา ลายเซ็น หรือการลงทุนด้านเครื่องมือที่มีอายุการใช้งานยาวนาน การแทนที่ไวยากรณ์จะต้องอาศัยการประสานงานของระบบนิเวศ ไม่ใช่แค่เพย์โหลดตัวอย่างที่สั้นลง
XML ยังมีประโยชน์เมื่อการแปลงและการสืบค้นตามเส้นทางเป็นศูนย์กลางของเวิร์กโฟลว์ JSON สามารถให้บริการโดเมนเหล่านี้ได้ด้วยข้อตกลงเพิ่มเติม เช่นเดียวกับที่ XML สามารถให้บริการ API ทั่วไปได้ แต่มูลค่าการย้ายจะต้องเกินต้นทุนสัญญาและเครื่องมือ ความนิยมในบริการที่ใช้เบราว์เซอร์ไม่ใช่ข้อพิสูจน์ถึงความเหนือกว่าสำหรับปัญหาการนำเสนอทุกอย่าง และการกล่าวอ้างที่ไม่ได้รับการสนับสนุนของการแทนที่ทั้งหมดได้รับการแก้ไขหรือละเว้น
สิ่งนี้ไม่ครอบคลุมถึง
สิ่งนี้ไม่ครอบคลุม — ทางเลือกไบนารี เช่น Protocol Buffers และ MessagePack ซึ่งแข่งขันกันในเงื่อนไขที่ต่างกัน ขนาดสายไฟ ข้อกำหนดสคีมา พฤติกรรมการสตรีม และเครื่องมือ จำเป็นต้องมีการประเมินแยกต่างหาก และไม่ได้เปรียบเทียบแบบแผนไฮเปอร์มีเดีย โปรโตคอลการขนส่ง หรือสไตล์ API SOAP กับ REST ไม่ใช่แค่ XML กับ JSON และการเป็นตัวแทนอย่างใดอย่างหนึ่งสามารถเดินทางผ่าน HTTP ได้
นี่ยังไม่ใช่ประวัติเชิงปริมาณที่มีแหล่งที่มาของการนำไปใช้ API ข้อความที่แม่นยำเกี่ยวกับวันที่ เปอร์เซ็นต์ การใช้งานครั้งแรก หรือสาเหตุทั่วทั้งอุตสาหกรรมไม่ได้รับการสนับสนุนจากหลักฐานที่เก็บที่ระบุไว้ ดังนั้นจึงละเว้นหรือแก้ไข บทความนี้จะอธิบายความสามารถในการจัดรูปแบบที่สังเกตได้และผลที่ตามมาทางวิศวกรรมที่เป็นไปได้ โดยไม่นำเสนอผลที่ตามมาเหล่านั้นเพื่อเป็นข้อพิสูจน์ของการเล่าเรื่องทางประวัติศาสตร์ที่สมบูรณ์
ประเด็นสำคัญ: JSON ชนะด้วยความเรียบง่าย ไม่ใช่ความสมบูรณ์
ประเด็นสำคัญ: JSON กลายเป็นค่าเริ่มต้นทั่วไปสำหรับ Web API จำนวนมากผ่านโมเดลข้อมูลขนาดกะทัดรัด การสนับสนุนโดยตรงในภาษากระแสหลัก และเครื่องมือโดยรอบที่ครอบคลุม ไม่ใช่เพราะมีคุณลักษณะทุกอย่างที่ XML นำเสนอ XML ยังคงเหมาะสมโดยที่โครงสร้างเอกสาร เนมสเปซ การแปลง หรือสคีมาที่สร้างขึ้นเป็นศูนย์กลาง การเลือกรูปแบบเป็นไปตามสัญญาและระบบนิเวศมากกว่าการจัดอันดับสากล
ToolAcre สะท้อนถึงโมเดลแคบของ JSON โดยการแยกวิเคราะห์ ตรวจสอบ และพิมพ์สวย JSON บนเส้นทางนี้ ไม่รับรอง API ซีแมนทิกส์ หรือทำให้ XML ล้าสมัย ใช้การแปลงข้ามรูปแบบเฉพาะเมื่อการแมปที่กำหนดไว้รักษาข้อมูลที่จำเป็นไว้ รักษาประวัติด้วยความระมัดระวังเท่าๆ กัน: การกล่าวอ้างที่ไม่ได้รับการสนับสนุนเกี่ยวกับจุดเปลี่ยนจุดเดียวหรือการแทนที่โดยสมบูรณ์จะถูกละเว้นหรือแก้ไข ทิ้งกลไกและพฤติกรรมปัจจุบันที่สามารถปกป้องได้