Pada tahun 2005, Jesse James Garrett menulis artikel "Ajax - Pendekatan Baru untuk Aplikasi Web", yang menjelaskan sebuah aplikasi bernama Ajax (teknologi Asynchronous JavaScript+XML). Teknik ini melibatkan pengiriman permintaan data tambahan ke server tanpa menyegarkan halaman, sehingga menghasilkan pengalaman pengguna yang lebih baik. Garrett menjelaskan bagaimana teknologi ini mengubah model klik-dan-tunggu tradisional yang telah ada sejak lahirnya Web.
Teknologi kunci yang mendorong Ajax ke panggung sejarah adalah objek XMLHttpRequest (XHR). Sebelum munculnya XHR, komunikasi gaya Ajax harus dicapai melalui beberapa teknologi hitam, terutama menggunakan panel tersembunyi atau panel inline. XHR menyediakan antarmuka yang masuk akal untuk mengirim permintaan server dan mendapatkan tanggapan. Antarmuka ini dapat memperoleh data tambahan dari server secara asinkron, artinya pengguna dapat memperoleh data tanpa me-refresh halaman. Setelah mendapatkan data melalui objek XHR, Anda dapat menggunakan metode DOM untuk memasukkan data ke dalam halaman web.
API objek XHR umumnya dianggap sulit untuk digunakan, dan Fetch API dengan cepat menjadi standar alternatif yang lebih modern untuk XHR setelah lahir secara otomatis. Fetch API mendukung janji terjadwal dan thread layanan (pekerja layanan), dan telah menjadi web yang sangat kuat alat pengembangan.
Keterbatasan utama komunikasi Ajax melalui XHR adalah kebijakan keamanan lintas asal. Secara default, XHR hanya dapat mengakses sumber daya di domain yang sama dengan halaman yang memulai permintaan. Pembatasan keamanan ini mencegah perilaku jahat tertentu. Namun, browser juga perlu mendukung akses lintas asal yang sah.
Berbagi Sumber Daya Lintas Asal (CORS) mendefinisikan bagaimana browser dan server menerapkan komunikasi lintas asal. Ide dasar di balik CORS adalah menggunakan header HTTP khusus untuk memungkinkan browser dan server saling memahami untuk menentukan apakah suatu permintaan atau respons harus berhasil atau gagal.
Untuk permintaan sederhana, seperti permintaan GET atau POST, tidak ada header khusus, dan isi permintaan bertipe teks/polos. Permintaan tersebut akan memiliki header tambahan yang disebut Asal saat dikirim. Header Asal berisi sumber (protokol, nama domain, port) dari halaman yang mengirimkan permintaan sehingga server dapat menentukan apakah akan memberikan respons untuk permintaan tersebut.
Browser modern secara asli mendukung CORS melalui objek XMLHttpRequst, yang secara otomatis dipicu ketika mencoba mengakses sumber daya dari sumber yang berbeda. Untuk mengirim permintaan ke asal di domain berbeda, Anda dapat menggunakan objek XHR standar dan meneruskan URL absolut ke metode open(), misalnya:
let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
alert(xhr.reaponseText);
}kalau tidak{
alert("Permintaan tidak berhasil:"+xhr.status);
}
}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null); Objek XHR lintas domain memungkinkan akses ke properti status dan statusText, dan juga mengizinkan sinkronisasi Permintaan objek XHR lintas domain juga menerapkan beberapa batasan tambahan untuk alasan keamanan.
Anda tidak dapat menggunakan setRequestHeader() untuk menyetel header khusus;
Anda tidak dapat mengirim dan menerima cookie;
metode getAllResponseHeaders() selalu mengembalikan string kosong
karena antarmuka yang sama digunakan untuk permintaan domain yang sama dan lintas domain, yang terbaik adalah kapan mengakses sumber daya lokal Gunakan URL relatif dan gunakan URL absolut saat mengakses sumber daya jarak jauh. Hal ini dapat membedakan skenario penggunaan dengan lebih jelas dan menghindari masalah akses terbatas ke informasi header atau cookie saat mengakses sumber daya lokal.
CORS menggunakan mekanisme verifikasi server yang disebut permintaan preflight, memungkinkan penggunaan header khusus, metode selain GET dan POST, dan tipe konten isi permintaan yang berbeda. Saat mengirim permintaan yang melibatkan salah satu opsi lanjutan di atas, permintaan preflight dikirim terlebih dahulu ke server. Permintaan ini dikirim menggunakan metode OPTIONS dan berisi header berikut:
Asal: sama dengan permintaan sederhana;
Access-Control-Request-Method: metode yang ingin Anda gunakan;
Access-Control-Request-Headers: (opsional) koma -nilai yang dipisahkan untuk menggunakan daftar header Kustom;
Fetch API dapat melakukan semua tugas objek XMLHttpRequest, tetapi lebih mudah digunakan, antarmuka lebih modern, dan dapat digunakan dalam alat Web seperti sebagai Utas pekerja web. XMLHttpRequest dapat memilih untuk menjadi asynchronous, sedangkan Fetch API harus asynchronous.
Metode Fetch() diekspos dalam lingkup global, termasuk thread eksekusi halaman utama, modul, dan thread pekerja. Memanggil metode ini menyebabkan browser mengirimkan permintaan ke URL yang diberikan.
1. Permintaan pengiriman
ambil() hanya memiliki satu input parameter yang diperlukan. Dalam kebanyakan kasus, parameter ini adalah URL untuk mendapatkan sumber daya, dan metode ini mengembalikan janji:
let r = ambil('/bar');console.log(r);//Janji<pending> Format URL (jalur relatif , jalur absolut, dll.) diinterpretasikan sama dengan objek XHR.
Ketika permintaan selesai dan sumber daya tersedia, objek Respons akan diproses. Objek ini merupakan enkapsulasi API yang melaluinya sumber daya terkait dapat diperoleh. Gunakan properti dan metode objek ini untuk mendapatkan sumber daya, memahami respons, dan mengubah penyeimbangan beban menjadi bentuk yang berguna.
2. Membaca respon. Cara paling sederhana untuk membaca konten respon adalah dengan mendapatkan konten dalam format teks biasa, cukup gunakan metode text(). Metode ini mengembalikan janji, yang memutuskan untuk mengambil seluruh konten sumber daya.
3. Menangani kode status dan kegagalan permintaan
Fetch API mendukung pemeriksaan status respons melalui properti status dan statusText dari Response. Permintaan yang berhasil mendapatkan respon biasanya menghasilkan kode status dengan nilai 200.
4. Mode permintaan Ambil Umum:
Kirim data JSON,
kirim parameter di badan permintaan,
kirim file
, muat file Blob
, kirim permintaan lintas domain,
interupsi permintaan
Soket websocket Tujuan dari websocket adalah untuk mencapai dupleks penuh dan dua- cara komunikasi dengan server melalui koneksi jangka panjang. Saat membuat soket web di JavaScript, permintaan HTTP dikirim ke server untuk menginisialisasi koneksi. Setelah server merespons, koneksi beralih dari protokol HTTP ke protokol websocket menggunakan header Upgrade di HTTP, yang berarti websocket tidak dapat diimplementasikan melalui server HTTP standar, tetapi harus menggunakan server berpemilik yang mendukung protokol ini.
Karena websocket menggunakan protokol khusus, skema URL sedikit berubah. http:// atau https:// tidak dapat digunakan lagi, tetapi ws:// dan wss:// harus digunakan. Yang pertama adalah koneksi tidak aman dan yang terakhir adalah koneksi aman. Saat menjalankan URL soket web, skema URL harus disertakan karena ada kemungkinan skema tambahan didukung di masa mendatang.
Keuntungan menggunakan protokol khusus dibandingkan protokol HTTP adalah klien dan server dapat mengirimkan data yang sangat sedikit tanpa menimbulkan beban apa pun pada HTTP. Menggunakan paket data yang lebih kecil membuat websockets ideal untuk aplikasi seluler yang memiliki masalah bandwidth dan latensi yang signifikan. Kerugian menggunakan protokol khusus adalah pendefinisian protokol memerlukan waktu lebih lama dibandingkan pendefinisian API JavaScript. Websocket didukung oleh semua browser utama.
