Haruskah saya mem-parsing XML di server atau memberikan proxy dan membiarkan browser menguraikannya?

11

Saya perlu berinteraksi dengan API pihak ke-3. Dengan API ini saya membuat permintaan GET dari dalam browser pengguna akhir dan menerima respons XML. Data ini akan digunakan dalam aplikasi berbasis browser di mana pengguna dapat mencari melalui itu, menggunakannya untuk membuat keputusan, dll. Masalah utama adalah bahwa sebagian besar browser telah mengunci penggunaan XML lintas-domain, jadi saya tidak bisa begitu saja mendapatkan XML dari API.

Keseluruhan data, pada dasarnya, dipecah menjadi dua set.

Rangkaian data pertama bersifat publik dan hanya perlu diperbarui sesering mungkin, sehingga dapat di-cache untuk semua pengguna di sisi server, meringankan lalu lintas secara signifikan.
Set data kedua bersifat pribadi dan individual untuk setiap pengguna. Data ini juga lebih sering diperbarui di API. Ini menyebabkan caching menjadi kurang efektif.

Untuk alasan skalabilitas, saya ingin agar server memuat sekecil mungkin.

Saya melihat dua opsi sebelum saya:

Berikan proxy yang dapat digunakan untuk merutekan permintaan XML ke server pihak ke-3 dan langsung bolak-balik antara klien dan API pihak ke-3.
Mintalah server melakukan konversi dari XML ke JSON dan menghapus informasi yang tidak perlu. Ini pada dasarnya berarti membuat API baru untuk server kami, yang diterjemahkan menjadi permintaan dari API pihak ke-3

Apa cara terbaik untuk menyediakan data kepada pengguna? (Tidak harus menjadi salah satu dari dua opsi)

— amethystdragon
sumber

Apa hubungan sumber XML dengan kode yang menafsirkannya di browser? Karena jika Anda telah menulis kode klien Anda sendiri (tidak didukung) untuk memberi makan dari beberapa data pihak ke-3, hal pertama yang saya pikirkan adalah bahwa suatu hari pihak ke-3 itu akan membuat beberapa perubahan kecil dalam XML dan menghancurkan aplikasi Anda untuk selamanya.

— SJuan76

Pihak ketiga memperbarui versi API mereka sekali. Mereka menyimpan versi lama sebentar agar orang dapat memperbarui kode mereka untuk menggunakan API baru. Namun, struktur data dalam XML tidak berubah setelah didefinisikan kecuali antara versi API.

— amethystdragon

1

Jika API sering berubah, mungkin perlu waktu Anda untuk mendeklarasikan skema Anda sendiri dan memiliki layanan yang bertindak sebagai middleware, memanipulasi data menjadi sesuatu yang diharapkan klien Anda. Saya pikir pertanyaannya adalah 'Mana yang lebih mudah, memperbarui klien atau memperbarui server?'

— Hyperbole

Itu tidak sering. Itu telah berubah sekali dalam 10 tahun.

— amethystdragon

12

Opsi proxy adalah yang paling mudah diterapkan. Anda tidak memiliki pengembangan kustom untuk dilakukan, satu-satunya yang harus dilakukan adalah menyiapkan proxy. Ini juga mudah: tidak ada kode tambahan untuk dipelihara, dan jika API berubah, Anda tidak perlu membuat perubahan di sisi Anda.

Proxy akan menjadi pilihan yang lebih disukai:

Jika Anda perlu mengirimkan perangkat lunak yang berfungsi dengan cepat. Ini menjadikannya pilihan yang baik, misalnya, jika Anda hendak mengirimkan fitur, tetapi ditemukan selama fase implementasi proyek bahwa Anda tidak bisa hanya membuat permintaan AJAX lintas-domain.
Atau jika API saat ini dirancang dengan baik : arsitekturnya bagus, panggilannya sangat jelas, dokumentasinya lengkap dan mudah dimengerti.
Atau jika API saat ini dapat berubah. Jika berubah, Anda hanya perlu mengubah implementasi JavaScript. Jika alih-alih proxy, Anda mem-parsing hasil dan menghasilkan JSON Anda sendiri, ada risiko bahwa perubahan pada API akan memerlukan perubahan dalam kode sisi server Anda.

Di sisi lain, penguraian hasil memiliki manfaat untuk memungkinkan untuk sepenuhnya abstrak API di sisi klien. Ini adalah alternatif yang lebih lambat, karena ia harus mendesain antarmuka baru (jika API asli tidak dirancang dengan baik) dan untuk mengimplementasikan fitur ekstrak, transformasi, dan pemuatan, tetapi mungkin merupakan pilihan jangka panjang yang baik untuk proyek besar. Ini adalah pilihan yang lebih disukai:

Jika Anda membutuhkan fitur tambahan. Anda dapat memanfaatkan berbagai fitur yang tidak tersedia di API asli, seperti caching pada tingkat yang tidak didukung oleh server proxy biasa, atau enkripsi , atau model otentikasi yang berbeda .

Misalnya, jika jumlah permintaan AJAX menjadi masalah atau jika model komunikasi dua arah masuk akal, Anda dapat menerapkan Soket Web.
Atau jika API saat ini tidak dirancang dengan baik. Seperti pola fasad, pendekatan ini memungkinkan Anda mendesain ulang API. Jika yang asli buruk, memiliki fasad memungkinkan untuk menyelesaikan pilihan desain buruk yang dibuat oleh penulis asli API lama. Anda dapat bertindak juga pada sebagian besar, seperti keseluruhan arsitektur API, tetapi juga pada detail, seperti nama argumen atau pesan kesalahan.

Meskipun memodifikasi API yang ada kadang-kadang tidak mungkin, memiliki fasad dapat memungkinkan untuk bekerja dengan sepotong kode bersih yang mengabstraksi kelemahan dan kesalahan dalam desain aslinya.
Atau jika API saat ini dapat berubah. Memang, Anda mungkin lebih suka mengubah kode sisi server daripada JavaScript jika API berubah seiring waktu, sambil menjaga antarmuka publik fasad Anda tidak terpengaruh. Mungkin lebih mudah karena Anda lebih berpengalaman dengan pemrograman sisi server atau karena Anda tahu lebih banyak alat untuk refactoring sisi server atau karena lebih mudah dalam proyek Anda untuk berurusan dengan versi kode sisi server.

Anda mungkin memperhatikan bahwa saya mengabaikan berbicara tentang JSON, kinerja, caching, dll. Ada alasan untuk itu:

JSON vs. XML: terserah Anda untuk memilih teknologi yang tepat . Anda melakukannya dengan mengukur secara obyektif overheat XML atas JSON, waktu yang diperlukan untuk membuat serialisasi data dan kemudahan parsing.
Kinerja: membandingkan penerapan yang berbeda, memilih yang tercepat, lalu membuat profil dan mengoptimalkannya berdasarkan hasil dari profiler. Berhenti ketika Anda mencapai kinerja yang ditentukan dalam persyaratan non-fungsional.

Pahami juga apa yang ingin Anda capai. Ada beberapa bagian yang saling berinteraksi: API asli, bandwidth antara server Anda dan API, kinerja server Anda, bandwidth antara server Anda dan pengguna akhir dan kinerja mesin mereka. Jika Anda diminta untuk mendapatkan respons terhadap permintaan dalam waktu 30 ms., Tetapi API asli menghabiskan 40 ms. memproses permintaan, apa pun yang Anda lakukan, Anda tidak akan dapat memperoleh kinerja yang diperlukan.
Caching: caching adalah salah satu teknik untuk membuat aplikasi web Anda merasa lebih cepat, mengurangi bandwidth, dll.
1. Pastikan Anda menggunakan caching klien juga (caching sisi-server tidak akan mengurangi penggunaan bandwidth antara Anda dan pelanggan), mengingat bahwa pengaturan tajuk HTTP dengan benar seringkali rumit.
2. Pastikan Anda menentukan dengan benar apa yang akan di-cache, untuk berapa lama dan kapan harus membatalkannya: jika deskripsi produk berubah 10 detik yang lalu, tetapi pelanggan situs web e-commerce masih melihat versi yang lama, tidak apa-apa. Jika pemilik mengubah deskripsi, mengirimkannya, dan masih melihat varian sebelumnya karena caching, ini bermasalah.
3. Jangan hanya fokus pada caching. Minifikasi, misalnya, juga penting. Mengurangi jumlah permintaan juga bisa bermanfaat.

— Arseni Mourzenko
sumber

1

+1 Saya ragu-ragu sedikit tentang apakah saya harus menyebutkan caching atau tidak dan akhirnya memutuskan untuk tidak melakukannya. Masih layak untuk diangkat, poin bagus.

— JensG

7

Ada opsi ketiga yang mungkin belum Anda lihat: Cross Origin Resource Sharing (CORS) .

Standar CORS berfungsi dengan menambahkan header HTTP baru yang memungkinkan server untuk menyajikan sumber daya ke domain asal yang diizinkan. Browser mendukung tajuk ini dan menghormati batasan yang mereka buat.

Contoh : Katakanlah situs Anda adalah http://my-cool-site.com dan, Anda memiliki API pihak ketiga di domain http://third-party-site.com , yang dapat Anda akses melalui AJAX.

Dan mari kita asumsikan bahwa halaman yang Anda server dari my-cool-site.com membuat permintaan ke pihak ketiga-site.com. Biasanya, browser pengguna akan menolak panggilan AJAX ke situs lain selain dari domain / subdomain Anda sendiri sesuai Kebijakan Keamanan Same-Origin . Tetapi jika browser dan server pihak ketiga mendukung CORS, hal-hal berikut ini terjadi:

Browser akan mengirimkan tajuk HTTP berikut ke pihak ketiga-situs.com
```
Origin: http://my-cool-site.com
```
Jika server pihak ketiga menerima permintaan dari domain Anda, itu akan merespons dengan tajuk HTTP berikut:
```
Access-Control-Allow-Origin: http://my-cool-site.com
```
Untuk mengizinkan semua domain, server pihak ketiga dapat mengirim tajuk ini:
```
Access-Control-Allow-Origin: *
```
Jika situs Anda tidak diizinkan, browser akan menampilkan kesalahan.

Jika klien memiliki browser yang cukup modern yang mendukung CORS , dan server pihak ketiga Anda mendukung CORS juga, Anda pasti dapat melakukannya dengan perubahan kecil pada kode Anda.

Saya menemukan penjelasan yang bagus tentang CORS , di mana Anda juga akan menemukan cara lain untuk melakukan ini: JSONP . Tetapi JSONP akan membutuhkan banyak perubahan pada kode Anda.

Untuk membuat permintaan CORS Anda cukup menggunakan XMLHttpRequestdi Firefox 3.5+, Safari 4+ dan Chrome dan XDomainRequestobjek di IE8 +. Saat menggunakan XMLHttpRequestobjek, jika browser melihat bahwa Anda mencoba membuat permintaan lintas domain, itu akan memicu perilaku CORS.

Berikut adalah fungsi javascript yang membantu Anda membuat objek CORS lintas browser.
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;
}

Karena Anda mengatakan bahwa "sebagian besar browser telah mengunci penggunaan lintas-domain XML", saya kira server pihak ketiga Anda mungkin tidak mendukung CORS. Maka Anda harus menemukan pendekatan alternatif.

— sampathsris
sumber

1

Bisakah Anda mencoba dan meringkas konten dalam tautan? Tautan rentan terhadap pembusukan tautan dan karenanya bukan cara terbaik untuk menyampaikan informasi tentang SE :)

— Ampt

Sayangnya server pihak ke-3 tidak mendukung CORS.

— amethystdragon

4

Untuk alasan skalabilitas, saya ingin agar server memuat sekecil mungkin

Saya kira ini kurang lebih menunjuk pada jawabannya. Apakah atau tidak memberikan data yang diproses untuk klien atau tidak tergantung pada:

perbedaan berkaitan dengan lalu lintas
dampak kinerja dari pemrosesan
dampak dari format data yang berbeda pada klien

Jika XML itu berukuran kecil atau hanya ada beberapa permintaan, masuk akal untuk meneruskannya ke klien dan melupakannya. Hal yang sama berlaku ketika data pracroses masih merupakan bagian besar dari data asli, atau jika klien tidak dapat mengambil untung banyak dari format data yang berbeda (katakanlah JSON, misalnya).

Namun, jika klien kesulitan dalam memproses kumpulan data XML yang besar, atau jika klien hanya membutuhkan sebagian kecil dari data XML asli, maka mungkin masuk akal untuk melakukan beberapa preprocessing di sisi server.

Pada akhirnya, lebih mudah untuk skala server, daripada skala klien / browser atau bandwidth yang tersedia. Untuk memasukkannya ke dalam satu kalimat, itu tergantung di mana kemacetan dalam sistem.

— JensG
sumber

+1, dan menambahkan - menguji kinerja dalam berbagai situasi.

— SeraM

0

Pilihan saya adalah melakukan cache dan kompres (membuang informasi yang tidak perlu) dan hasil gzip ke browser klien, pilihan Anda # 2 . Karena browser biasanya bukan CPU kelas atas dan server ke jalur jaringan browser memiliki kapasitas terbatas. Saya berbicara tentang klien seluler . Jika Anda tidak berencana untuk mendukung klien seluler maka pilih apa pun yang lebih sederhana, misalnya beberapaGoogle:CORS proxy

— xmojmr
sumber