ฉันควรแยกวิเคราะห์ XML บนเซิร์ฟเวอร์หรือระบุพรอกซีและให้เบราว์เซอร์แยกวิเคราะห์หรือไม่

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

แม้ว่าข้อมูลโดยรวมจะแบ่งออกเป็นสองชุด

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

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

ฉันเห็นสองตัวเลือกก่อนหน้าฉัน:

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

อะไรจะเป็นวิธีที่ดีที่สุดในการให้ข้อมูลแก่ผู้ใช้? (ไม่จำเป็นต้องเป็นหนึ่งในสองตัวเลือก)

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

พร็อกซีจะเป็นตัวเลือกที่ต้องการ:

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

• หรือถ้า API ปัจจุบันได้รับการออกแบบมาอย่างดี : สถาปัตยกรรมดีการโทรนั้นชัดเจนเอกสารประกอบเสร็จสมบูรณ์และเข้าใจง่าย

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

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

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

  ตัวอย่างเช่นถ้าจำนวนคำขอ AJAX กลายเป็นปัญหาหรือหากรูปแบบการสื่อสารสองทางเหมาะสมคุณสามารถใช้ Web Sockets

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

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

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

คุณอาจสังเกตเห็นว่าฉันละเว้นการพูดคุยเกี่ยวกับ JSON, ประสิทธิภาพ, แคชเป็นต้นมีเหตุผลที่:

• JSON กับ XML:ขึ้นอยู่กับคุณที่จะเลือกเทคโนโลยีที่เหมาะสม คุณทำได้โดยการวัดความร้อนเกินของ XML ผ่านทาง JSON อย่างเป็นรูปธรรมเวลาที่ใช้ในการจัดลำดับข้อมูลและความง่ายในการแยกวิเคราะห์

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

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

• การแคช: การแคชเป็นหนึ่งในเทคนิคที่ทำให้เว็บแอปพลิเคชันของคุณรู้สึกเร็วขึ้นลดแบนด์วิดท์เป็นต้น

  1. ตรวจสอบให้แน่ใจว่าคุณใช้การแคชไคลเอ็นต์ด้วย (การแคชฝั่งเซิร์ฟเวอร์จะไม่ลดการใช้แบนด์วิดท์ระหว่างคุณและลูกค้า) เนื่องจากการตั้งค่าส่วนหัว HTTP อย่างถูกต้องมักเป็นเรื่องยุ่งยาก

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

  3. อย่ามุ่งเน้นไปที่แคชเท่านั้น ตัวอย่างเช่นการย่อส่วนก็มีความสำคัญเช่นกัน การลดจำนวนคำขออาจเป็นประโยชน์เช่นกัน

มีเป็นสามตัวเลือกที่คุณอาจไม่ได้เห็น: ข้ามแหล่งกำเนิดทรัพยากรร่วมกัน ( ธ )

มาตรฐาน CORS ทำงานโดยการเพิ่มส่วนหัว HTTP ใหม่ซึ่งอนุญาตให้เซิร์ฟเวอร์ให้บริการทรัพยากรไปยังโดเมนต้นทางที่ได้รับอนุญาต เบราว์เซอร์สนับสนุนส่วนหัวเหล่านี้และเคารพข้อ จำกัด ที่สร้างขึ้น

ตัวอย่าง : สมมติว่าไซต์ของคุณคือhttp://my-cool-site.comและคุณมี API บุคคลที่สามที่โดเมนhttp://third-party-site.comซึ่งคุณสามารถเข้าถึงได้ผ่าน AJAX

และสมมติว่าหน้าเว็บที่คุณเซิร์ฟเวอร์จาก my-cool-site.com ส่งคำขอไปยัง third-party-site.com โดยปกติเบราว์เซอร์ผู้ใช้จะปฏิเสธการโทร AJAX ไปยังไซต์อื่น ๆ นอกเหนือจากโดเมน / โดเมนย่อยของคุณตามนโยบายความปลอดภัยต้นทางเดียวกัน แต่ถ้าเบราว์เซอร์และเซิร์ฟเวอร์บุคคลที่สามรองรับ CORS สิ่งต่อไปนี้จะเกิดขึ้น:

• เบราว์เซอร์จะส่งส่วนหัว HTTP ต่อไปนี้ไปยัง third-party-site.com

  Origin: http://my-cool-site.com

• หากเซิร์ฟเวอร์บุคคลที่สามยอมรับคำขอจากโดเมนของคุณเซิร์ฟเวอร์จะตอบกลับด้วยส่วนหัว HTTP ต่อไปนี้:

  Access-Control-Allow-Origin: http://my-cool-site.com

• หากต้องการอนุญาตโดเมนทั้งหมดเซิร์ฟเวอร์บุคคลที่สามสามารถส่งส่วนหัวนี้:

  Access-Control-Allow-Origin: *

• หากเว็บไซต์ของคุณไม่ได้รับอนุญาตเบราว์เซอร์จะโยนข้อผิดพลาด

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

ผมพบว่าคำอธิบายที่ดีในล ธซึ่งคุณยังจะหาวิธีที่จะทำเช่นนี้อีก: JSONP แต่ JSONP จะต้องมีการเปลี่ยนแปลงรหัสของคุณอย่างยุติธรรม

เพื่อทำการร้องขอ CORS คุณเพียงใช้XMLHttpRequestใน Firefox 3.5+, Safari 4+ และ Chrome และXDomainRequestวัตถุใน IE8 + เมื่อใช้XMLHttpRequestวัตถุหากเบราว์เซอร์เห็นว่าคุณพยายามที่จะขอข้ามโดเมนมันจะเรียกพฤติกรรม CORS ได้อย่างราบรื่น

นี่คือฟังก์ชั่นจาวาสคริปต์ที่ช่วยให้คุณสร้างวัตถุข้ามเบราว์เซอร์ CORS

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        // XHR has 'withCredentials' property only if it supports CORS
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

เนื่องจากคุณบอกว่า "เบราว์เซอร์ส่วนใหญ่ล็อคการใช้ข้ามโดเมน XML" ฉันเดาว่าเซิร์ฟเวอร์บุคคลที่สามของคุณอาจไม่รองรับ CORS จากนั้นคุณต้องค้นหาวิธีการอื่น

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

ฉันคิดว่านี่เป็นสิ่งที่ชี้ไปที่คำตอบไม่มากก็น้อย การให้ข้อมูลที่ดำเนินการล่วงหน้าให้กับลูกค้าหรือไม่นั้นขึ้นอยู่กับว่า:

1. ความแตกต่างเกี่ยวกับการจราจร
2. ผลกระทบต่อประสิทธิภาพของการประมวลผล
3. ผลกระทบของรูปแบบข้อมูลอื่นบนไคลเอ็นต์

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

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

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

ทางเลือกของฉันจะแคชและการบีบอัด (ทิ้งข้อมูลที่ไม่จำเป็น) และผล gzip เบราว์เซอร์ลูกค้าของคุณ# 2 ตัวเลือก เนื่องจากเบราว์เซอร์ไม่ใช่ซีพียูระดับไฮเอนด์และเซิร์ฟเวอร์ไปยังสายเครือข่ายของเบราว์เซอร์มีความจุ จำกัด ผมกำลังพูดถึงลูกค้ามือถือ หากคุณไม่ได้วางแผนที่จะสนับสนุนลูกค้ามือถือให้เลือกสิ่งที่ง่ายกว่าเช่นบางอย่างGoogle:CORS proxy