มีอะไรผิดปกติกับจุดสิ้นสุดที่ส่งคืน HTML แทนที่จะเป็นข้อมูล JSON

เมื่อฉันเริ่มเรียนรู้ PHP ครั้งแรก (ประมาณ 5 หรือ 6 ปีก่อน) ฉันเรียนรู้เกี่ยวกับAjaxและฉันผ่าน "ขั้นตอน":

1. เซิร์ฟเวอร์ของคุณส่งคืนข้อมูล HTML และคุณวางไว้ในinnerHTML ของ DOM
2. คุณเรียนรู้เกี่ยวกับรูปแบบการถ่ายโอนข้อมูลเช่น XML (และพูดว่า "oooh นั่นคือสิ่งที่มันใช้สำหรับ") แล้ว JSON
3. คุณส่งคืน JSON และสร้าง UI ของคุณโดยใช้รหัสวานิลลา JavaScript
4. คุณย้ายไปที่ jQuery
5. คุณเรียนรู้เกี่ยวกับ API, ส่วนหัว, รหัสสถานะ HTTP, REST , CORSและBootstrap
6. คุณเรียนรู้SPAและเฟรมเวิร์กส่วนหน้า ( React , Vue.jsและAngularJS ) และมาตรฐาน JSON API
7. คุณได้รับรหัสดั้งเดิมขององค์กรและจากการตรวจสอบพบว่าพวกเขาทำสิ่งที่อธิบายไว้ในขั้นตอนที่ 1

ขณะที่ฉันทำงานกับ codebase ดั้งเดิมฉันไม่ได้คิดว่ามันจะส่งคืน HTML (ฉันหมายความว่าตอนนี้เราเป็นมืออาชีพใช่มั้ย) ดังนั้นฉันจึงยากที่จะมองหาจุดปลาย JSON ที่ส่งคืนข้อมูลที่ การเรียก Ajax จะเติมข้อมูล มันไม่ได้จนกว่าฉันจะถาม "โปรแกรมเมอร์" ที่เขาบอกฉันว่ามันกลับ HTML และถูกผนวกเข้าโดยตรงกับ DOM ด้วย innerHTML

แน่นอนว่ามันยากที่จะยอมรับ ฉันเริ่มคิดหาวิธีที่จะทำให้สิ่งนี้เป็นจุดสิ้นสุดของ JSON โดยคิดถึงการทดสอบหน่วยปลายทางและอื่น ๆ อย่างไรก็ตาม codebase นี้ไม่มีการทดสอบ ไม่ใช่คนเดียว และมันมีมากกว่า 200k เส้น แน่นอนหนึ่งในภารกิจของฉันรวมถึงการเสนอแนวทางสำหรับการทดสอบทั้งหมด แต่ในขณะนี้เรายังไม่ได้แก้ปัญหา

ดังนั้นฉันไม่มีที่มุมสงสัย: ถ้าเราไม่มีการทดสอบใด ๆ ดังนั้นเราจึงไม่มีเหตุผลพิเศษที่จะสร้างจุดสิ้นสุด JSON นี้ (เนื่องจากไม่ใช่ "นำมาใช้ซ้ำ": มันจะส่งคืนข้อมูลที่เหมาะกับส่วนนั้นของ แอปพลิเคชัน แต่ฉันคิดว่านี่เป็นนัยแล้วเพราะมัน ... ส่งคืนข้อมูล HTML)

อะไรกันแน่ที่เป็นธรรมกับการทำเช่นนี้?

มีอะไรผิดปกติกับจุดสิ้นสุดที่ส่งคืน HTML แทนที่จะเป็นข้อมูล JSON

ไม่มีอะไรจริงๆ. แต่ละแอปพลิเคชันมีข้อกำหนดที่แตกต่างกันและอาจเป็นไปได้ว่าแอปพลิเคชันของคุณไม่ได้ออกแบบมาให้เป็นสปา

อาจเป็นไปได้ว่ากรอบงานที่สวยงามเหล่านี้ที่คุณอ้างถึง (Angular, Vue, React, ฯลฯ ... ) ไม่สามารถใช้ได้ในช่วงการพัฒนาหรือไม่ได้รับการอนุมัติ "enterprisey" สิ่งที่ต้องใช้ในองค์กรของคุณ

ฉันจะบอกคุณนี้: ปลายทางที่ส่งคืน HTML จะลดการพึ่งพาไลบรารี JavaScript และลดการโหลดบนเบราว์เซอร์ของผู้ใช้เนื่องจากไม่จำเป็นต้องตีความ / เรียกใช้รหัส JS เพื่อสร้างวัตถุ DOM - HTML มีอยู่แล้ว มันเป็นเพียงเรื่องของการแยกวิเคราะห์องค์ประกอบและการแสดงผล แน่นอนนี่หมายความว่าเรากำลังพูดถึงปริมาณข้อมูลที่สมเหตุสมผล ข้อมูล HTML ขนาด 10 เมกะไบต์ไม่สมเหตุสมผล

แต่เนื่องจากไม่มีอะไรผิดพลาดกับ HTML ที่ส่งคืนสิ่งที่คุณสูญเสียจากการไม่ใช้ JSON / XML จึงเป็นไปได้ที่จะใช้ปลายทางของคุณเป็น API และนี่คือคำถามที่ยิ่งใหญ่ที่สุด: จำเป็นหรือไม่ที่จะต้องเป็น API

ที่เกี่ยวข้อง: ตกลงเพื่อส่งคืน HTML จาก JSON API หรือไม่

JSON และ HTML ตอบสนองวัตถุประสงค์ที่แตกต่างกันสองวัตถุประสงค์

หากคุณกำลังเติมข้อมูลเว็บเพจให้ใช้ JSON หากคุณกำลังสร้างหน้าเว็บจากส่วนของหน้าเว็บให้ใช้ HTML

พวกเขาอาจจะฟังดูเหมือนพวกเขาจะเหมือนกัน แต่ก็ไม่ได้เลย สิ่งหนึ่งเมื่อคุณสร้างส่วนหนึ่งของหน้าเว็บโดยใช้ HTML ที่เซิร์ฟเวอร์ส่งคืนคุณกำลังทำงานกับฝั่งเซิร์ฟเวอร์ เมื่อคุณผูกข้อมูลกับเว็บเพจคุณกำลังทำงานกับฝั่งไคลเอ็นต์

นอกจากนี้คุณต้องระวังด้วย HTML เพื่อไม่ให้ผูกกับหน้าเว็บใดหน้าหนึ่งโดยเฉพาะ จุดทั้งหมดของการเรนเดอร์เพจบางส่วนด้วยวิธีนี้คือเพื่อให้ partials นั้นสามารถนำมาใช้ซ้ำได้และถ้าคุณสร้างบางส่วนที่เจาะจงเกินไปมันจะไม่เขียนไปยังเพจอื่น JSON ไม่มีปัญหานี้เพราะมันเป็นเพียงข้อมูลไม่ใช่โครงสร้างของหน้าเว็บ

ปัญหาหลักคือมันแน่นหนาคู่เซิร์ฟเวอร์กับลูกค้าที่ต้องรู้โครงสร้าง HTML นอกจากนี้ยังทำให้จุดสิ้นสุดยากต่อการใช้ซ้ำในรูปแบบใหม่หรือแอปพลิเคชันใหม่

การส่งคืนข้อมูลธรรมดาและให้ไคลเอนต์ทำให้การมีเพศสัมพันธ์ลดลงและเพิ่มความยืดหยุ่นและความสามารถในการทดสอบ - คุณสามารถเรียกใช้การทดสอบหน่วยบนไคลเอนต์สำหรับข้อมูลจำลองและเรียกใช้การทดสอบหน่วยบนเซิร์ฟเวอร์เพื่อทดสอบข้อมูลที่ต้องการ

ฉันคิดว่าคุณมีมันข้างหลังเล็กน้อย คุณพูด:

เราไม่มีการทดสอบใด ๆ ดังนั้นเราจึงไม่มีเหตุผลใดที่จะสร้าง JSON endpoint นี้

เหตุผลในการใช้จุดปลายที่เหมาะสมคือเพื่อให้คุณสามารถทดสอบได้ ฉันจะบอกว่าไม่มีการทดสอบเป็นเหตุผลที่ดีมากที่จะเริ่มเขียนบางอย่าง นั่นคือถ้ามีตรรกะใด ๆ ที่จะเหมาะที่จะทดสอบ

บรรทัดโค้ดขนาด 200k นั้นมีจำนวนมากในการปรับโครงสร้างและอาจยากต่อการบำรุงรักษา การหาจุดสิ้นสุดและทดสอบพวกมันอาจเป็นจุดเริ่มต้นที่ดี

อีกสาเหตุหนึ่งก็คือการแยกเซิร์ฟเวอร์ออกจากไคลเอนต์ หากในอนาคตอันไกลการออกแบบแอพพลิเคชั่นหรือการเปลี่ยนแปลงเลย์เอาต์จะง่ายกว่าที่จะทำงานกับรูปแบบข้อมูลที่เหมาะสมกว่าเอาท์พุท HTML ในโลกอุดมคติคุณจะต้องเปลี่ยนไคลเอนต์และไม่ต้องแตะเซิร์ฟเวอร์เลย

มี 3 วิธี (อย่างน้อย?) ในการสร้างหน้าเว็บ:

• สร้างฝั่งเซิร์ฟเวอร์ทั้งหน้า
• ส่งคืนหน้าเปล่าจากเซิร์ฟเวอร์พร้อมรหัส (JavaScript) และให้หน้าดึงข้อมูลและแสดงผลในฝั่งไคลเอ็นต์ HTML
• ส่งคืนบางส่วนของหน้าพร้อมรหัสและดึงรหัสบล็อกที่แสดงผลล่วงหน้าของ HTML ที่สามารถวางลงในหน้า

อันแรกก็โอเค ส่วนที่สองก็ใช้ได้เช่นกัน เป็นคนสุดท้ายที่เป็นปัญหา

เหตุผลง่าย: ตอนนี้คุณได้แบ่งการสร้างหน้า HTML ออกเป็นส่วนที่ไม่ได้เชื่อมต่ออย่างสมบูรณ์ ปัญหาคือหนึ่งในการบำรุงรักษา ตอนนี้คุณมีสองเอนทิตีแยกต่างหากที่รับผิดชอบการจัดการรายละเอียดของ UI ดังนั้นคุณต้องเก็บ CSS และรายละเอียดอื่น ๆ ที่คล้ายคลึงกันให้ตรงกันระหว่างสองส่วนแยกกัน คุณเปลี่ยนความกว้างของแถบด้านข้างหรือไม่ ยิ่งใหญ่ ตอนนี้การแยกส่วน HTML ที่กลับมาทำให้เกิดการเลื่อนในแนวนอนเนื่องจากสมมติฐานเกี่ยวกับความกว้างของแถบด้านข้างไม่ได้ถูกเก็บไว้อีกต่อไป คุณเปลี่ยนสีพื้นหลังสำหรับบล็อกนั้นหรือไม่ เยี่ยมมากตอนนี้สีแบบอักษรของส่วน HTML ของคุณขัดแย้งกันเพราะถือว่ามีสีพื้นหลังที่แตกต่างกันและมีคนลืมทดสอบจุดปลายทางนั้น

ประเด็นก็คือตอนนี้คุณได้แยกความรู้ที่ควรจะรวมศูนย์ไว้ในที่เดียว (เช่นตรรกะการนำเสนอ) และทำให้ยากขึ้นเพื่อให้แน่ใจว่าชิ้นส่วนทั้งหมดเข้าด้วยกันอย่างถูกต้อง ด้วยการใช้ JSON API คุณสามารถเก็บตรรกะทั้งหมดนั้นไว้ในส่วนหน้าหรือคุณสามารถเก็บไว้ในแม่แบบฝั่งเซิร์ฟเวอร์ของคุณถ้าคุณแสดงข้อมูลของคุณเป็น HTML เพื่อเริ่มต้นด้วย มันเกี่ยวกับการนำเสนอความรู้ / ตรรกะในที่เดียวดังนั้นมันจึงสามารถจัดการได้อย่างสม่ำเสมอและเป็นส่วนหนึ่งของกระบวนการเดียว HTML / CSS / JS นั้นยากพอที่จะทำให้ตรงโดยไม่ทำให้มันกลายเป็นชิ้นเล็ก ๆ

JSON APIs ยังมีประโยชน์เพิ่มเติมในการทำให้ข้อมูลพร้อมใช้งานอย่างสมบูรณ์โดยอิสระจากตรรกะการนำเสนอ สิ่งนี้อนุญาตให้ผู้นำเสนอหลายคนที่แตกต่างกันเช่นทั้งแอพมือถือและเว็บเพจใช้ข้อมูลเดียวกัน โดยเฉพาะอย่างยิ่งมันช่วยให้การบริโภคข้อมูลโดยไม่ต้องเบราว์เซอร์ (เช่นแอพมือถือหรืองาน cron ทุกคืน); ผู้บริโภคเหล่านี้อาจไม่สามารถแยกวิเคราะห์ HTML ได้ (หลักสูตรนี้จำเป็นต้องอาศัยสถานการณ์ที่ข้อมูลเหมือนกันระหว่างผู้บริโภคที่แตกต่างกันหรือผู้ใช้สามารถใช้ชุดย่อยอื่น ๆ ได้) ไม่ว่าคุณต้องการความสามารถนี้หรือไม่ขึ้นอยู่กับข้อกำหนดของแอปพลิเคชันเฉพาะของคุณ ตรรกะเป็นสิ่งที่จำเป็นโดยไม่คำนึงถึง ฉันจะบอกว่าถ้าคุณใช้มันล่วงหน้าคุณจะพร้อมสำหรับการเติบโตในอนาคต

ฉันจะบอกว่าไม่มีอะไรผิดปกติกับเซิร์ฟเวอร์ที่ส่งคืนชิ้นส่วน HTML และ UI กำหนดให้. ภายใน HTML ขององค์ประกอบบางอย่าง นี่คือความคิดของฉันวิธีที่ง่ายที่สุดในการพัฒนาโค้ด JavaScript แบบอะซิงโครนัส ประโยชน์คือการใช้ JavaScript ให้น้อยที่สุดเท่าที่จะทำได้ในสภาพแวดล้อมแบ็คเอนด์ที่มีการควบคุม โปรดจำไว้ว่าการรองรับ JavaScript ในเบราว์เซอร์แตกต่างกันไป แต่ส่วนท้ายของคุณมักจะมีส่วนประกอบของส่วนหลังเหมือนกันซึ่งหมายความว่าการทำมากที่สุดในส่วนหลังจะหมายถึงความเข้ากันไม่ได้ของรุ่นที่เล็กที่สุด

ตอนนี้บางครั้งคุณต้องการมากกว่าแค่ส่วนย่อย HTML ตัวอย่างเช่นรหัสสถานะและแฟรกเมนต์ HTML จากนั้นคุณสามารถใช้อ็อบเจ็กต์ JSON ที่มีสองสมาชิก statusCode และ HTML ซึ่งสามารถกำหนดที่สองให้กับ. innerHTML ขององค์ประกอบบางส่วนหลังจากตรวจสอบ statusCode ดังนั้นการใช้ JSON และการใช้ innerHTML จึงไม่ใช่ทางเลือกพิเศษ พวกเขาสามารถใช้ร่วมกัน

โดยใช้ JSON คุณสามารถมีหลายส่วน HTML ในการตอบสนองเดียวกันซึ่งได้รับมอบหมายให้. innerHTML ขององค์ประกอบหลาย ๆ

โดยสรุป: ใช้. innerHTML มันทำให้รหัสของคุณเข้ากันได้กับเบราว์เซอร์เวอร์ชันมากที่สุด หากต้องการมากกว่านี้ให้ใช้ JSON และ .innerHTML ร่วมกัน หลีกเลี่ยง XML

มีอะไรผิดปกติคือในหลักการ คำถามคือคุณต้องการบรรลุอะไร

JSON นั้นสมบูรณ์แบบสำหรับการส่งข้อมูล หากคุณส่ง HTML แทนและคาดว่าลูกค้าจะดึงข้อมูลจาก HTML นั่นเป็นขยะ

ในทางตรงกันข้ามถ้าคุณต้องการส่ง HMTL ที่จะแสดงเป็น HTML จากนั้นส่งเป็น HTML - แทนที่จะบรรจุ HTML เป็นสตริงเปลี่ยนสตริงเป็น JSON ส่ง JSON ถอดรหัสอีกด้านหนึ่ง รับสตริงและแยก HTML ออกจากสตริง

และเมื่อวานนี้ฉันพบโค้ดที่ใส่สองรายการลงในอาร์เรย์เปลี่ยนอาร์เรย์เป็น JSON ใส่ JSON ลงในสตริงใส่สตริงภายในอาร์เรย์เปลี่ยนทั้งอาร์เรย์เป็น JSON ส่งไปยังไคลเอ็นต์ซึ่งถอดรหัส JSON ได้รับอาร์เรย์ที่มีสตริงเอาสตริงดึง JSON จากสตริงถอดรหัส JSON และได้อาร์เรย์ที่มีสองรายการ อย่าทำอย่างนั้น

ทั้งหมดนี้ขึ้นอยู่กับวัตถุประสงค์ของ API แต่โดยทั่วไปสิ่งที่คุณอธิบายมีการละเมิดข้อกังวลอย่างมาก :

ในแอปพลิเคชันที่ทันสมัยรหัส API ควรรับผิดชอบข้อมูลและรหัสลูกค้าควรรับผิดชอบการนำเสนอ

เมื่อ API ของคุณส่งคืน HTML คุณจะเชื่อมโยงข้อมูลและงานนำเสนอของคุณอย่างแน่นหนา เมื่อ API ส่งคืน HTML สิ่งเดียวที่คุณสามารถทำได้ (อย่างง่ายดาย) เมื่อใช้ HTML นั้นแสดงเป็นส่วนหนึ่งของหน้าขนาดใหญ่ จากมุมที่แตกต่างสิ่งเดียวที่ดีสำหรับ API คือการส่งหน้าเว็บของคุณด้วย HTML นอกจากนี้คุณได้เผยแพร่ HTML ของคุณทั้งในไคลเอนต์และเซิร์ฟเวอร์ ซึ่งสามารถทำให้การบำรุงรักษาปวดหัว

หาก API ของคุณส่งคืน JSON หรือข้อมูลบริสุทธิ์บางรูปแบบมันจะมีประโยชน์มากขึ้น แอพที่มีอยู่ยังคงสามารถใช้ข้อมูลนั้นและนำเสนอได้อย่างเหมาะสม แม้ว่าตอนนี้สิ่งอื่น ๆ สามารถใช้ API เพื่อเข้าถึงข้อมูลเดียวกันได้ การบำรุงรักษาก็ง่ายขึ้นเช่นกัน HTML ทั้งหมดอยู่ในที่เดียวดังนั้นหากคุณต้องการจัดรูปแบบทั้งไซต์ใหม่คุณไม่จำเป็นต้องเปลี่ยน API ของคุณ

HTML นั้นเชื่อมโยงกับการออกแบบและการใช้งานเฉพาะ

ด้วย HTML หากคุณต้องการเปลี่ยนเค้าโครงเพจคุณต้องเปลี่ยนวิธีการสร้าง HTML โดยการเรียกเซิร์ฟเวอร์ โดยปกติแล้วต้องใช้โปรแกรมเมอร์ส่วนท้าย ตอนนี้คุณมีโปรแกรมเมอร์แบ็คเอนด์ซึ่งตามนิยามแล้วไม่ใช่นักเขียน html ที่ดีที่สุดของคุณจัดการการอัพเดตเหล่านี้

ด้วย JSON หากเลย์เอาต์ของเพจเปลี่ยนแปลงการโทรเซิร์ฟเวอร์ JSON ที่มีอยู่ไม่จำเป็นต้องเปลี่ยนเลย ผู้พัฒนาส่วนหน้าของคุณหรือแม้กระทั่งนักออกแบบจะอัปเดตเทมเพลตเพื่อสร้าง HTML ที่แตกต่างที่คุณต้องการจากข้อมูลพื้นฐานเดียวกัน

นอกจากนี้ JSON สามารถเป็นพื้นฐานสำหรับบริการอื่น ๆ คุณอาจมีบทบาทที่แตกต่างกันซึ่งจำเป็นต้องดูข้อมูลพื้นฐานเดียวกันในวิธีที่ต่างกัน ตัวอย่างเช่นคุณอาจมีเว็บไซต์ลูกค้าที่แสดงข้อมูลเกี่ยวกับผลิตภัณฑ์ในหน้าคำสั่งซื้อและหน้าขายภายในสำหรับพนักงานที่แสดงข้อมูลเดียวกันในรูปแบบที่แตกต่างกันมากบางทีอาจอยู่ข้างข้อมูลอื่น ๆ ที่ไม่สามารถใช้ได้กับลูกค้าทั่วไป ด้วย JSON การเรียกเซิร์ฟเวอร์เดียวกันสามารถใช้ในทั้งสองมุมมอง

ในที่สุด JSON สามารถปรับขนาดได้ดีขึ้น ในช่วงไม่กี่ปีที่ผ่านมาเราได้ไปตกอยู่ในกรอบจาวาสคริปต์ทางฝั่งไคลเอ็นต์ ฉันคิดว่าถึงเวลาแล้วที่จะต้องถอยห่างออกไปและเริ่มคิดถึงจาวาสคริปต์ที่เราใช้อยู่และมันส่งผลต่อประสิทธิภาพของเบราว์เซอร์อย่างไร ... โดยเฉพาะบนอุปกรณ์มือถือ ที่กล่าวว่าหากคุณใช้งานเว็บไซต์ที่ใหญ่พอที่จะต้องใช้เซิร์ฟเวอร์ฟาร์มหรือคลัสเตอร์แทนที่จะเป็นเซิร์ฟเวอร์เดียว JSON สามารถปรับขนาดได้ดีขึ้น ผู้ใช้จะให้เวลาในการประมวลผลในเบราว์เซอร์ฟรีและถ้าคุณใช้ประโยชน์จากสิ่งที่คุณสามารถลดภาระของเซิร์ฟเวอร์ในการปรับใช้ขนาดใหญ่ JSON ยังใช้แบนด์วิดท์น้อยลงดังนั้นถ้าคุณใหญ่พอและใช้อย่างเหมาะสม JSON นั้นถูกกว่า แน่นอนว่ามันสามารถลดขนาดลงได้ถ้าคุณจบการป้อน 40KB ไลบรารี่เพื่อแยก 2KB ของข้อมูลเป็น 7KB ของ html ดังนั้นอีกครั้ง: จ่ายเพื่อให้ตระหนักถึงสิ่งที่คุณทำ แต่มีศักยภาพสำหรับ JSON เพื่อปรับปรุงประสิทธิภาพและค่าใช้จ่าย

ไม่มีอะไรผิดปกติกับจุดสิ้นสุดดังกล่าวหากตอบสนองความต้องการของมัน หากจำเป็นต้องแยก html ที่ผู้ใช้ที่รู้จักสามารถแยกวิเคราะห์ได้อย่างมีประสิทธิภาพแน่นอนว่าทำไมไม่

ปัญหาคือสำหรับกรณีทั่วไปคุณต้องการให้จุดปลายของคุณคาย payload ที่มีรูปแบบที่ดีและแยกวิเคราะห์ได้อย่างมีประสิทธิภาพโดย parser มาตรฐาน และโดยการแยกวิเคราะห์ได้อย่างมีประสิทธิภาพฉันหมายถึงแยกวิเคราะห์ได้อย่างชัดเจน

หากไคลเอ็นต์ของคุณถูกบังคับให้อ่านบิตข้อมูล payload และ pry open จากมันด้วยลูปและ if-statements ดังนั้นจึงไม่สามารถแยกวิเคราะห์ได้อย่างมีประสิทธิภาพ และ HTML นั้นเป็นวิธีการที่ได้รับการอภัยอย่างมากโดยไม่ต้องการให้ตัวเองมีรูปแบบที่เหมาะสม

ตอนนี้ถ้าคุณแน่ใจว่า html ของคุณเป็นไปตามมาตรฐาน xml แสดงว่าคุณเป็นทองคำ

จากที่กล่าวมาฉันมีปัญหาสำคัญกับสิ่งนี้:

ฉันจะบอกคุณนี้: ปลายทางที่ส่งคืน HTML จะลดการพึ่งพาไลบรารี JavaScript และลดภาระในเบราว์เซอร์ผู้ใช้เนื่องจากไม่จำเป็นต้องตีความ / เรียกใช้รหัส JS เพื่อสร้างวัตถุ DOM - HTML มีอยู่แล้ว มันเป็นเพียงเรื่องของการแยกวิเคราะห์องค์ประกอบและการแสดงผล แน่นอนนี่หมายความว่าเรากำลังพูดถึงปริมาณข้อมูลที่สมเหตุสมผล ข้อมูล HTML ขนาด 10 เมกะไบต์ไม่สมเหตุสมผล

นั่นเป็นความคิดที่ไม่ดีไม่ว่าคุณจะตัดมันอย่างไร ทศวรรษของประสบการณ์ในอุตสาหกรรมโดยรวมได้แสดงให้เราเห็นว่าโดยทั่วไปแล้วมันเป็นความคิดที่ดีที่จะแยกข้อมูล (หรือรุ่น) ออกจากจอแสดงผล (หรือมุมมอง)

ที่นี่คุณกำลังแช่งสองสิ่งเพื่อจุดประสงค์ในการเรียกใช้โค้ด JS อย่างรวดเร็ว และนั่นคือการเพิ่มประสิทธิภาพขนาดเล็ก

ฉันไม่เคยเห็นสิ่งนี้เป็นความคิดที่ดียกเว้นในระบบที่ไม่สำคัญมาก

คำแนะนำของฉัน? อย่าทำมัน HC SVNT DRACONES , YMMV เป็นต้น

JSON เป็นเพียงการนำเสนอที่เป็นข้อความของข้อมูลที่มีโครงสร้าง ลูกค้าต้องมีโปรแกรมแยกวิเคราะห์เพื่อประมวลผลข้อมูล แต่ทุกภาษามีฟังก์ชั่นวิเคราะห์คำ JSON การใช้ตัวแยกวิเคราะห์ JSON นั้นมีประสิทธิภาพมากกว่าการใช้ตัวแยกวิเคราะห์ HTML ใช้เวลาเพียงเล็กน้อย ไม่เช่นนั้นกับ parser HTML

ใน PHP คุณเพียงแค่ใช้json_encode($data)และมันก็ขึ้นอยู่กับลูกค้าในด้านอื่น ๆ เพื่อแยกมัน และเมื่อคุณดึงข้อมูล JSON จากบริการเว็บคุณเพียงแค่ใช้$data=json_decode($response)และคุณสามารถตัดสินใจได้ว่าจะใช้ข้อมูลอย่างไรเช่นเดียวกับตัวแปร

สมมติว่าคุณพัฒนาแอพสำหรับอุปกรณ์พกพาทำไมคุณถึงต้องการรูปแบบ HTML เมื่อแอพมือถือไม่ค่อยใช้เว็บเบราว์เซอร์ในการวิเคราะห์ข้อมูล แอพมือถือจำนวนมากใช้ JSON (รูปแบบที่พบบ่อยที่สุด) เพื่อแลกเปลี่ยนข้อมูล

เมื่อพิจารณาว่าโทรศัพท์มือถือมักมีแผนแบบมิเตอร์ทำไมคุณต้องการใช้ HTML ที่ใช้แบนด์วิดท์มากกว่า JSON มาก

ทำไมต้องใช้ HMTL เมื่อ HTML ถูก จำกัด ในคำศัพท์และ JSON สามารถกำหนดข้อมูลได้ {"person_name":"Jeff Doe"}มีข้อมูลมากกว่า HTML สามารถให้ข้อมูลเกี่ยวกับข้อมูลได้เนื่องจากจะกำหนดโครงสร้างสำหรับตัวแยกวิเคราะห์ HTML เท่านั้นไม่ใช่กำหนดข้อมูล

JSON ไม่มีส่วนเกี่ยวข้องกับ HTTP คุณสามารถใส่ JSON ในไฟล์ คุณสามารถใช้มันสำหรับการกำหนดค่า นักแต่งเพลงใช้ JSON คุณสามารถใช้มันเพื่อบันทึกตัวแปรอย่างง่ายไปยังไฟล์ได้เช่นกัน

เป็นการยากที่จะจัดหมวดหมู่ถูกหรือผิด IMO คำถามที่ฉันถามคือ: " ควร " หรือ " ทำได้น้อยกว่านี้หรือ "

จุดสิ้นสุดทุกจุดควรพยายามสื่อสารด้วยเนื้อหาที่น้อยที่สุดเท่าที่จะทำได้ อัตราส่วนสัญญาณต่อสัญญาณรบกวนมักจะเป็นรหัส HTTP <JSON <XHTML ในสถานการณ์ส่วนใหญ่คุณควรเลือกโปรโตคอลที่มีเสียงรบกวนน้อยที่สุด

ฉันแตกต่างกันตรงประเด็นเกี่ยวกับโหลดเบราว์เซอร์ไคลเอ็นต์โดย @machado เช่นเดียวกับเบราว์เซอร์ที่ทันสมัยนี่ไม่ใช่ปัญหา ส่วนใหญ่มีการจัดการกับรหัส HTTP และการตอบสนอง JSON ค่อนข้างดี และถึงแม้ว่าคุณจะไม่ได้ทำการทดสอบในตอนนี้ แต่การบำรุงรักษาโปรโตคอลที่มีเสียงดังน้อยกว่าในระยะยาวจะถูกกว่าที่กล่าวไว้ข้างต้น