Bagi banyak pengembang Web, membuat permintaan sederhana dan menerima respons sederhana sudah cukup; tetapi bagi pengembang yang ingin menguasai Ajax, pemahaman lengkap tentang kode status HTTP, status siap, dan objek XMLHttpRequest diperlukan. Dalam artikel ini, Brett McLaughlin memperkenalkan Anda pada berbagai kode status dan menunjukkan bagaimana browser menanganinya. Ia juga membahas beberapa permintaan HTTP yang kurang umum digunakan di Ajax.
Pada artikel sebelumnya di seri ini, kita melihat lebih dekat objek XMLHttpRequest, yang merupakan inti dari aplikasi Ajax dan bertanggung jawab untuk menangani permintaan dari aplikasi dan skrip sisi server serta memproses data yang dikembalikan dari komponen sisi server. Karena semua aplikasi Ajax menggunakan objek XMLHttpRequest, Anda mungkin ingin membiasakan diri dengan objek ini agar Ajax dapat bekerja lebih baik.
Pada artikel ini, saya akan fokus pada tiga bagian penting dari objek permintaan ini berdasarkan artikel sebelumnya:
· Status siap HTTP · Kode status HTTP · Jenis permintaan yang dapat dihasilkan.
Ketiga bagian ini semuanya dalam membangun sebuah Faktor yang perlu dipertimbangkan ketika meminta; namun, terlalu sedikit yang ditulis mengenai topik ini. Namun, jika Anda ingin mempelajari lebih dari sekedar dasar-dasar pemrograman Ajax, Anda harus membiasakan diri dengan konten status siap pakai, kode status, dan permintaan itu sendiri. Ketika ada yang tidak beres dengan aplikasi Anda - dan selalu terjadi - jika Anda memahami dengan benar status kesiapan, cara membuat permintaan HEAD, atau apa sebenarnya arti kode status 400, Anda dapat men-debug masalah dalam 5 menit, bukan 5 jam yang dihabiskan dalam berbagai frustrasi dan kebingungan.
Pertama-tama mari kita lihat status siap HTTP.
Melihat lebih dekat status siap HTTP
Anda akan ingat dari artikel sebelumnya bahwa objek XMLHttpRequest memiliki properti bernama readyState. Atribut ini memastikan bahwa server telah menyelesaikan permintaan, biasanya menggunakan fungsi panggilan balik untuk membaca data dari server guna memperbarui konten formulir atau halaman Web. Listing 1 menunjukkan contoh sederhana (ini juga merupakan contoh dari artikel sebelumnya dalam seri ini - lihat Sumberdaya).
XMLHttpRequest atau XMLHttp: Perubahan Nama
Microsoft™ dan Internet Explorer menggunakan objek bernama XMLHttp dan bukan objek XMLHttpRequest, yang digunakan oleh Mozilla, Opera, Safari, dan sebagian besar browser non-Microsoft. Demi kesederhanaan, saya akan menyebut kedua objek tersebut dengan XMLHttpRequest. Hal ini konsisten dengan apa yang kita lihat di Web dan niat Microsoft untuk menggunakan XMLHttpRequest sebagai objek permintaan di Internet Explorer 7.0. (Lihat Bagian 2 untuk informasi lebih lanjut mengenai masalah ini.)
Listing 1. Menangani respons server dalam
fungsi panggilan balik updatePage() {
if (permintaan.readyState == 4) {
if (permintaan.status == 200) {
var respon = permintaan.responseText.split("|");
document.getElementById("pesanan").nilai = respons[0];
dokumen.getElementById("alamat").innerHTML =
respon[1].ganti(/n/g, "
");
} kalau tidak
alert("statusnya adalah " + permintaan.status);
}
}
Ini jelas merupakan penggunaan keadaan siap yang paling umum (dan paling sederhana). Seperti yang Anda ketahui dari angka "4", ada beberapa status siap lainnya (Anda juga melihat daftar ini di artikel sebelumnya - lihat Sumberdaya):
· 0: Permintaan tidak diinisialisasi ( open() belum dipanggil) .
·1: Permintaan telah dibuat, tetapi belum terkirim (send() belum dipanggil).
·2: Permintaan telah dikirim dan sedang diproses (biasanya header konten sekarang dapat diperoleh dari respons).
·3: Permintaan sedang diproses; biasanya beberapa data tersedia dalam respons, tetapi server belum selesai menghasilkan respons.
·4: Respons selesai; Anda dapat memperoleh dan menggunakan respons server.
Jika Anda ingin memahami lebih dari dasar-dasar pemrograman Ajax, Anda perlu mengetahui tidak hanya keadaan ini, tetapi juga kapan keadaan tersebut terjadi dan bagaimana cara menggunakannya. Pertama, Anda perlu mempelajari status permintaan mana yang mungkin Anda temui di setiap status kesiapan. Sayangnya, hal ini tidak intuitif dan melibatkan beberapa kasus khusus.
Status siap tersembunyi
Status siap pertama ditandai dengan atribut readyState menjadi 0 (readyState == 0), yang menunjukkan status tidak diinisialisasi. Properti ini disetel ke 1 setelah open() dipanggil pada objek permintaan. Karena Anda biasanya memanggil open() segera setelah menginisialisasi sepasang permintaan, Anda jarang akan melihat status readyState == 0. Selain itu, keadaan siap yang tidak diinisialisasi tidak memiliki kegunaan nyata dalam aplikasi nyata.
Namun untuk kepentingan kami, lihat Listing 2, yang menunjukkan cara mendapatkan status siap ini ketika readyState disetel ke 0.
Listing 2. Mendapatkan 0 status siap
fungsi getSalesData() {
//Buat objek permintaan
buatPermintaan();
alert("Status siap adalah: " + request.readyState);
// Siapkan (inisialisasi) permintaan
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, benar);
request.onreadystatechange = updatePage;
permintaan.kirim(null);
}
Dalam contoh sederhana ini, getSalesData() adalah fungsi yang dipanggil halaman Web untuk memulai permintaan (misalnya saat tombol diklik). Perhatikan bahwa Anda harus memeriksa status siap sebelum memanggil open(). Gambar 1 menunjukkan hasil menjalankan aplikasi ini.
Gambar 1. Keadaan siap 0
Jelas ini tidak memberi banyak manfaat bagi Anda; hanya ada sedikit situasi di mana Anda perlu memastikan bahwa fungsi open() belum dipanggil. Di dunia nyata sebagian besar pemrograman Ajax, satu-satunya penggunaan status siap ini adalah dengan menggunakan objek XMLHttpRequest yang sama untuk menghasilkan banyak permintaan di berbagai fungsi. Dalam kasus (yang jarang terjadi) ini, Anda mungkin ingin memastikan bahwa objek permintaan berada dalam keadaan tidak diinisialisasi (readyState == 0) sebelum membuat permintaan baru. Ini pada dasarnya memastikan bahwa fungsi lain tidak menggunakan objek tersebut pada saat yang bersamaan.
Melihat status kesiapan dari permintaan yang sedang diproses
, selain status siap 0, objek permintaan juga harus melalui beberapa status siap lainnya dari permintaan dan respons tipikal, dan akhirnya berakhir dalam bentuk status siap 4. Inilah sebabnya mengapa Anda melihat baris if (request.readyState == 4) di sebagian besar fungsi panggilan balik; ini memastikan bahwa server telah selesai memproses permintaan dan sekarang aman untuk memperbarui halaman web atau memperbarui halaman berdasarkan permintaan yang dikembalikan. dari server.
Sangat mudah untuk melihat bagaimana keadaan ini terjadi. Jika status siap adalah 4, kita tidak hanya harus menjalankan kode dalam fungsi panggilan balik, tetapi kita juga mencetak status siap setiap kali fungsi panggilan balik dipanggil. Listing 3 memberikan contoh penerapan fungsi ini.
Ketika 0 sama dengan 4
, Anda perlu memeriksa status siap 0 untuk memastikan bahwa objek permintaan tidak digunakan ketika beberapa fungsi JavaScript menggunakan objek permintaan yang sama. Mekanisme ini dapat menyebabkan masalah. Karena readyState == 4 mewakili permintaan yang telah selesai, Anda akan sering menemukan bahwa objek permintaan dalam status siap yang saat ini tidak digunakan masih disetel ke 4 - ini karena data yang dikembalikan dari server telah digunakan, tetapi tidak perubahan telah dilakukan sejak ditetapkan ke status siap. Ada fungsi abort() yang mengatur ulang objek permintaan, namun fungsi ini tidak benar-benar digunakan untuk tujuan ini. Jika Anda harus menggunakan beberapa fungsi, lebih baik membuat dan menggunakan satu fungsi untuk setiap fungsi daripada berbagi objek yang sama di antara beberapa fungsi.
Listing 3. Lihat
fungsi kesiapan updatePage() {
// Menampilkan status siap saat ini
alert("updatePage() dipanggil dengan status siap " + request.readyState);
}
Jika Anda tidak yakin bagaimana menjalankan fungsi ini, Anda perlu membuat sebuah fungsi, kemudian memanggil fungsi ini di halaman Web dan memintanya mengirimkan permintaan ke komponen sisi server (seperti fungsi yang ditunjukkan pada Listing 2, atau fungsi dalam rangkaian artikel ini) Contoh diberikan di Bagian 1 dan Bagian 2). Pastikan untuk menyetel fungsi panggilan balik ke updatePage() saat membuat permintaan; untuk melakukan ini, setel properti onreadystatechange objek permintaan ke updatePage().
Kode ini merupakan demonstrasi yang tepat dari arti onreadystatechange - setiap kali status siap dari permintaan berubah, updatePage() dipanggil, dan kemudian kita dapat melihat peringatan. Gambar 2 menunjukkan contoh pemanggilan fungsi ini, dengan status siap adalah 1.
Gambar 2. Keadaan siap 1
Anda dapat mencoba menjalankan kode ini sendiri. Masukkan ke dalam halaman Web dan aktifkan event handler (klik tombol, tab antar kolom, atau gunakan metode apa pun yang Anda atur untuk memicu permintaan). Fungsi panggilan balik ini akan berjalan beberapa kali - setiap kali status siap berubah - dan Anda dapat melihat peringatan untuk setiap status siap. Ini adalah cara terbaik untuk melacak berbagai tahapan yang dilalui suatu permintaan.
Inkonsistensi Browser
Setelah Anda memiliki pemahaman dasar tentang proses tersebut, cobalah mengakses halaman Anda dari beberapa browser yang berbeda. Anda harus memperhatikan bahwa browser tidak konsisten dalam cara mereka menangani status siap ini. Misalnya, di Firefox 1.5, Anda akan melihat status siap berikut:
·1
·2
·3
·4
Hal ini tidak mengherankan karena setiap status permintaan diwakili di sini. Namun, jika Anda menggunakan Safari untuk mengakses aplikasi yang sama, Anda akan melihat -- atau tidak -- sesuatu yang menarik. Berikut tampilannya di Safari 2.0.1:
·2
·3
·4
Safari sebenarnya membuang status siap pertama, dan tidak ada alasan yang jelas mengapa, tapi itulah cara kerja Safari. Hal ini juga mengilustrasikan poin penting: meskipun merupakan ide bagus untuk memastikan bahwa status permintaan adalah 4 sebelum menggunakan data di server, kode yang ditulis berdasarkan setiap status siap transisi memang akan terlihat berbeda pada hasil browser yang berbeda.
Misalnya, saat menggunakan Opera 8.5, status kesiapan yang ditampilkan bahkan lebih buruk lagi:
·3
·
4Terakhir, Internet Explorer akan menampilkan status berikut:
·1
·2
·3
·4Jika
Anda memiliki masalah dengan permintaan Anda, ini adalah tempat pertama yang harus Anda tuju untuk mengidentifikasi masalahnya. Cara terbaik adalah mengujinya di Internet Explorer dan Firefox - Anda akan melihat keempat status dan dapat memeriksa status masing-masing permintaan.
Selanjutnya, mari kita lihat situasi di sisi respons.
Data respon di bawah mikroskop
Setelah kita memahami berbagai keadaan kesiapan yang terjadi selama proses permintaan, sekarang saatnya untuk melihat aspek lain dari objek XMLHttpRequest - atribut responText. Mengingat apa yang kami perkenalkan di artikel sebelumnya, Anda dapat mengetahui bahwa atribut ini digunakan untuk mendapatkan data dari server. Setelah server selesai memproses permintaan, server dapat menempatkan data apa pun yang diperlukan untuk merespons data permintaan ke dalam respondText permintaan. Fungsi panggilan balik kemudian dapat menggunakan data ini, seperti yang ditunjukkan pada Listing 1 dan Listing 4.
Listing 4. Menggunakan respon yang dikembalikan di server
fungsi pembaruanHalaman() {
if (permintaan.readyState == 4) {
var newTotal = permintaan.responseText;
var totalSoldEl = document.getElementById("total terjual");
var netProfitEl = document.getElementById("laba bersih");
replaceText(totalSoldEl, newTotal);
/* Bayangkan laba bersih yang baru */
var boardCostEl = document.getElementById("biaya papan");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("biaya manusia");
var manCost = getText(manCostEl);
var profitPerBoard = boardCost - manCost;
var netProfit = profitPerBoard * newTotal;
/* Update laba bersih pada formulir penjualan */
netProfit = Matematika.bulat(netProfit * 100) / 100;
replaceText(netProfitEl, netProfit);
Listing
1 cukup sederhana; Listing 4 sedikit lebih rumit, namun keduanya memeriksa status siap di awal dan mendapatkan nilai properti responText.
Melihat teks respon permintaan
Mirip dengan keadaan siap, nilai properti responText juga berubah sepanjang masa permintaan. Untuk melihat perubahan ini, gunakan kode yang ditunjukkan pada Listing 5 untuk menguji teks respons permintaan, serta status kesiapannya.
Listing 5. Menguji fungsi properti responText
updatePage() {
// Menampilkan status siap saat ini
alert("updatePage() dipanggil dengan status siap " + request.readyState +
" dan teks respons '" + request.responseText + "'");
}
Sekarang buka aplikasi web di browser Anda dan aktifkan permintaan Anda. Untuk melihat efek kode ini dengan lebih baik, gunakan Firefox atau Internet Explorer, karena kedua browser dapat melaporkan semua kemungkinan status kesiapan selama permintaan. Misalnya, dalam keadaan siap 2, respondText tidak ditentukan (lihat Gambar 3); jika konsol JavaScript juga terbuka, Anda akan melihat kesalahan.
Gambar 3. Teks respon status siap 2
Namun, dalam keadaan siap 3, server telah memberi nilai pada properti responText, setidaknya dalam contoh ini (lihat Gambar 4).
Gambar 4. Teks respon status siap 3
Anda akan melihat bahwa respon dengan status siap 3 berbeda pada setiap skrip, setiap server, dan bahkan setiap browser. Namun, ini masih sangat berguna dalam men-debug aplikasi.
Memperoleh data yang aman
Semua dokumen dan spesifikasi menekankan bahwa data hanya dapat digunakan dengan aman ketika status kesiapannya adalah 4. Percayalah, ketika status siap adalah 3, Anda jarang akan menemukan situasi di mana Anda tidak bisa mendapatkan data dari properti responText. Namun, bukanlah ide yang baik untuk membuat logika Anda sendiri dalam aplikasi Anda bergantung pada status siap 3 - setelah Anda menulis kode yang mengandalkan data lengkap dalam status siap 3, Anda hampir bertanggung jawab atas data yang tidak lengkap pada saat itu.
Pendekatan yang lebih baik adalah dengan memberikan umpan balik kepada pengguna sehingga ketika dalam keadaan siap 3, respons akan segera diberikan. Meskipun menggunakan fungsi seperti alert() jelas merupakan ide yang buruk - menggunakan Ajax dan kemudian memblokir pengguna dengan kotak dialog peringatan jelas salah - Anda dapat memperbarui bidang dalam formulir atau halaman ketika status siap berubah. Misalnya, untuk status siap 1, atur lebar indikator kemajuan menjadi 25%, untuk status siap 2, atur lebar indikator kemajuan menjadi 50%, dan untuk status siap 3, atur lebar indikator kemajuan menjadi 25 %. Lebarnya diatur ke 75%, dan ketika status siap adalah 4, lebar indikator kemajuan diatur ke 100% (selesai).
Tentu saja, seperti yang telah Anda lihat, metode ini sangat pintar, tetapi bergantung pada browser. Di Opera Anda tidak pernah melihat dua status siap pertama, dan di Safari tidak ada status pertama (1). Oleh karena itu, saya meninggalkan kode ini sebagai latihan dan tidak memasukkannya ke dalam artikel ini.
Sekarang saatnya melihat kode status.
Melihat Lebih Dalam Kode Status HTTP
Dengan status siap dan respons server yang Anda pelajari di Teknik Pemrograman Ajax, Anda dapat menambahkan tingkat kerumitan lain ke aplikasi Ajax Anda -- menggunakan kode status HTTP. Tidak ada yang baru tentang Ajax dalam kode ini. Mereka sudah ada sejak awal mula Web. Anda mungkin pernah melihat beberapa kode status di browser Web:
· 401: Tidak Sah · 403: Terlarang · 404: Tidak Ditemukan
Anda dapat menemukan lebih banyak kode status (lihat Sumberdaya untuk daftar lengkap). Untuk menambahkan lapisan tambahan mekanisme kontrol dan respons (dan penanganan kesalahan yang lebih kuat) ke aplikasi Ajax Anda, Anda perlu melihat kode status dengan benar dalam permintaan dan respons.
200: Semuanya baik-baik saja
Di banyak aplikasi Ajax, Anda akan melihat fungsi panggilan balik yang bertanggung jawab untuk memeriksa status kesiapan dan kemudian terus memanfaatkan data yang dikembalikan dari respons server, seperti yang ditunjukkan pada Listing 6.
Listing 6. Fungsi panggilan balik yang mengabaikan
fungsi kode status updatePage() {
if (permintaan.readyState == 4) {
var respon = permintaan.responseText.split("|");
document.getElementById("pesanan").nilai = respons[0];
dokumen.getElementById("alamat").innerHTML =
respon[1].ganti(/n/g, "
");
}
}
Hal ini ternyata merupakan pendekatan yang picik dan salah terhadap pemrograman Ajax. Jika skrip memerlukan autentikasi dan permintaan tidak memberikan sertifikat yang valid, server akan mengembalikan kode kesalahan seperti 403 atau 401. Namun, karena server merespons permintaan tersebut, status siap disetel ke 4 (walaupun responsnya tidak sesuai dengan yang diharapkan permintaan). Pada akhirnya, pengguna tidak mendapatkan data yang valid, dan kesalahan serius dapat terjadi saat JavaScript mencoba menggunakan data server yang tidak ada.
Dibutuhkan sedikit usaha untuk memastikan bahwa server tidak hanya menyelesaikan permintaan, tetapi juga mengembalikan kode status "semuanya baik". Kode ini adalah "200", yang dilaporkan melalui atribut status objek XMLHttpRequest. Untuk memastikan bahwa server tidak hanya menyelesaikan permintaan tetapi juga melaporkan status OK, tambahkan pemeriksaan lain ke fungsi panggilan balik Anda, seperti yang ditunjukkan pada Listing 7.
Listing 7. Memeriksa kode status yang valid
fungsi updatePage() {
if (permintaan.readyState == 4) {
if (permintaan.status == 200) {
var respon = permintaan.responseText.split("|");
document.getElementById("pesanan").nilai = respons[0];
dokumen.getElementById("alamat").innerHTML =
respon[1].ganti(/n/g, "
");
} kalau tidak
alert("statusnya adalah " + permintaan.status);
}
}
Dengan menambahkan beberapa baris kode ini, Anda dapat mengonfirmasi jika ada masalah dan pengguna akan melihat pesan kesalahan yang berguna dibandingkan hanya melihat halaman yang terdiri dari data yang diambil di luar konteks tanpa penjelasan.
Pengalihan dan Pengalihan Rute
Sebelum kita membahas detail tentang kesalahan, ada baiknya membahas masalah yang tidak perlu Anda khawatirkan saat menggunakan Ajax - pengalihan. Di antara kode status HTTP, ini adalah 300 rangkaian kode status, termasuk:
301: Dipindahkan Secara Permanen 302: Ditemukan (permintaan dialihkan ke URL/URI lain)
·305: Menggunakan proxy (permintaan harus menggunakan proxy untuk mengakses sumber daya yang diminta)
Pemrogram Ajax mungkin tidak terlalu khawatir tentang masalah pengalihan, karena dua alasan:
·Pertama, aplikasi Ajax biasanya dirancang untuk Ditulis untuk sisi server tertentu skrip, servlet, atau aplikasi. Pemrogram Ajax kurang paham tentang komponen yang hilang tanpa Anda melihatnya. Jadi terkadang Anda mengetahui bahwa sumber daya telah dipindahkan (karena Anda memindahkannya, atau memindahkannya dengan cara tertentu), lalu Anda mengubah URL dalam permintaan dan tidak pernah menemukan hasil ini lagi.
Alasan yang lebih penting adalah aplikasi dan permintaan Ajax dienkapsulasi dalam sandbox. Artinya, domain yang melayani halaman Web yang menghasilkan permintaan Ajax haruslah domain yang merespons permintaan tersebut. Oleh karena itu, halaman Web yang disediakan oleh ebay.com tidak dapat membuat permintaan gaya Ajax ke skrip yang berjalan di amazon.com; aplikasi Ajax di ibm.com tidak dapat membuat permintaan ke servlet yang berjalan di netbeans.org.
·Hasilnya adalah permintaan Anda tidak dapat dialihkan ke server lain tanpa menimbulkan kesalahan keamanan. Dalam kasus ini, Anda tidak akan mendapatkan kode status sama sekali. Biasanya kesalahan JavaScript dihasilkan di konsol debug. Oleh karena itu, setelah cukup memikirkan kode status, Anda dapat mengabaikan masalah kode pengalihan sama sekali.
Hasilnya adalah permintaan Anda tidak dapat dialihkan ke server lain tanpa menimbulkan kesalahan keamanan. Dalam kasus ini, Anda tidak akan mendapatkan kode status sama sekali. Biasanya kesalahan JavaScript dihasilkan di konsol debug. Oleh karena itu, setelah cukup memikirkan kode status, Anda dapat mengabaikan masalah kode pengalihan sama sekali.
Kesalahan
Setelah Anda menerima kode status 200 dan menyadari bahwa Anda dapat mengabaikan sebagian besar kode status seri 300, satu-satunya rangkaian kode yang perlu Anda khawatirkan adalah kode seri 400, yang menggambarkan berbagai jenis kesalahan. Lihat kembali Listing 7 dan perhatikan bahwa saat menangani kesalahan, hanya beberapa pesan kesalahan umum yang ditampilkan kepada pengguna. Meskipun ini merupakan langkah ke arah yang benar, pesan-pesan ini masih belum terlalu berguna dalam memberi tahu pengguna dan pemrogram yang mengerjakan aplikasi apa yang sebenarnya salah.
Pertama, kami akan menambahkan dukungan untuk halaman tidak ditemukan. Hal ini seharusnya tidak terjadi di sebagian besar sistem produksi, namun tidak jarang terjadi ketika lokasi skrip pengujian berubah atau pemrogram memasukkan URL yang salah. Jika Anda dapat melaporkan kesalahan 404 secara alami, Anda dapat memberikan lebih banyak bantuan kepada pengguna dan pemrogram yang frustrasi. Misalnya, jika skrip di server dihapus, kita dapat menggunakan kode di Listing 7 sehingga pengguna melihat kesalahan non-deskriptif seperti yang ditunjukkan pada Gambar 5.
Kasus Edge dan Situasi Sulit
Pada titik ini, beberapa programmer pemula mungkin bertanya-tanya tentang apa ini. Inilah fakta yang perlu Anda ketahui: kurang dari 5% permintaan Ajax menggunakan status siap pakai seperti 2 dan 3 dan kode status seperti 403 (sebenarnya, tarif ini mungkin mendekati 1% atau bahkan kurang). Situasi ini sangat penting dan disebut kasus tepi - situasi ini hanya terjadi pada situasi yang sangat spesifik di mana masalah yang paling eksotik ditemui. Meskipun situasi ini tidak umum, kasus-kasus tepi ini menyumbang 80% dari masalah yang dihadapi sebagian besar pengguna!
Bagi pengguna rata-rata, fakta bahwa aplikasi berfungsi dengan benar 100 kali biasanya dilupakan, namun Satu kesalahan dalam aplikasi akan diingat dengan jelas oleh oleh. mereka. Jika Anda dapat menangani kasus-kasus sulit (atau situasi sulit) dengan baik, Anda dapat memberikan imbalan yang memuaskan bagi pengguna yang kembali ke situs Anda.
Gambar 5. Penanganan kesalahan umum
Pengguna tidak memiliki cara untuk mengetahui apakah masalahnya adalah masalah autentikasi, skrip tidak ditemukan (seperti yang terjadi di sini), kesalahan pengguna, atau hal lain dalam kode. Menambahkan beberapa kode sederhana dapat membuat kesalahan ini lebih spesifik. Silakan merujuk ke Listing 8, yang bertanggung jawab untuk menangani situasi di mana skrip tidak ditemukan atau terjadi kesalahan otentikasi, dan pesan khusus akan diberikan ketika kesalahan ini terjadi.
Listing 8. Memeriksa kode status yang valid
fungsi updatePage() {
if (permintaan.readyState == 4) {
if (permintaan.status == 200) {
var respon = permintaan.responseText.split("|");
document.getElementById("pesanan").nilai = respons[0];
dokumen.getElementById("alamat").innerHTML =
respon[1].ganti(/n/g, "
");
} else if (permintaan.status == 404) {
alert("URL yang diminta tidak ditemukan.");
} else if (permintaan.status == 403) {
alert("Akses ditolak.");
} kalau tidak
alert("statusnya adalah " + permintaan.status);
}
}
Meskipun hal ini masih cukup sederhana, hal ini memberikan sedikit informasi yang lebih berguna. Gambar 6 menunjukkan kesalahan yang sama seperti Gambar 5, tetapi kali ini kode penanganan kesalahan menjelaskan dengan lebih baik kepada pengguna atau pemrogram apa yang sebenarnya terjadi.
Gambar 6. Penanganan error khusus
Dalam aplikasi kita sendiri, kita mungkin mempertimbangkan untuk menghapus nama pengguna dan kata sandi dan menambahkan pesan kesalahan ke layar jika terjadi kegagalan otentikasi. Kita dapat menggunakan pendekatan serupa untuk menangani skrip tidak ditemukan atau kesalahan tipe 400 lainnya dengan lebih baik (misalnya, 405 berarti metode permintaan yang tidak dapat diterima seperti mengirim permintaan HEAD tidak diperbolehkan, dan 407 berarti otentikasi proxy diperlukan). Namun, opsi mana pun yang Anda pilih, Anda harus mulai memproses kode status yang dikembalikan dari server.
Jenis Permintaan Lainnya
Jika Anda benar-benar ingin memiliki kendali atas objek XMLHttpRequest, pertimbangkan untuk mengimplementasikan fungsi akhir ini dengan menambahkan permintaan HEAD ke direktif. Dalam dua artikel sebelumnya, kami telah memperkenalkan cara menghasilkan permintaan GET; di artikel mendatang, Anda akan mempelajari tentang penggunaan permintaan POST untuk mengirim data ke server. Namun, dalam semangat peningkatan penanganan kesalahan dan pengumpulan informasi, Anda harus mempelajari cara menghasilkan permintaan HEAD.
Membuat permintaan
Membuat permintaan HEAD sebenarnya sangat sederhana; Anda memanggil metode open() dengan "HEAD" (bukan "GET" atau "POST") sebagai parameter pertama, seperti yang ditunjukkan pada Listing 9.
Listing 9. Menggunakan Ajax untuk menghasilkan fungsi permintaan HEAD
getSalesData() {
buatPermintaan();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, benar);
request.onreadystatechange = updatePage;
permintaan.kirim(null);
}
Saat Anda membuat permintaan HEAD seperti ini, server tidak mengembalikan respons nyata seperti permintaan GET atau POST. Sebaliknya, server hanya mengembalikan header sumber daya, yang mencakup kapan konten dalam respons terakhir diubah, apakah sumber daya yang diminta ada, dan banyak informasi berguna lainnya. Anda dapat menggunakan informasi ini untuk mempelajari sumber daya sebelum diproses dan dikembalikan oleh server.
Hal paling sederhana yang dapat Anda lakukan untuk permintaan semacam ini adalah dengan menampilkan konten semua header respons. Ini memberi Anda gambaran tentang apa yang tersedia melalui permintaan HEAD. Listing 10 menyediakan fungsi panggilan balik sederhana yang mencetak konten header respons yang diperoleh dari permintaan HEAD.
Listing 10. Keluarkan isi header respons yang diperoleh dari
fungsi permintaan HEAD updatePage() {
if (permintaan.readyState == 4) {
peringatan(permintaan.getAllResponseHeaders());
}
}
Lihat Gambar 7, yang menunjukkan header respons yang dikembalikan dari aplikasi Ajax sederhana yang membuat permintaan HEAD ke server.
Anda dapat menggunakan header ini satu per satu (dari tipe server hingga tipe konten) untuk memberikan informasi atau fungsionalitas tambahan dalam aplikasi Ajax Anda.
Memeriksa URL
Anda telah melihat cara memeriksa kesalahan 404 ketika URL tidak ada. Jika ini ternyata menjadi masalah umum - mungkin skrip atau servlet tertentu hilang - maka Anda mungkin ingin memeriksa URL sebelum membuat permintaan GET atau POST secara lengkap. Untuk mengimplementasikan fungsi ini, buat permintaan HEAD dan kemudian periksa kesalahan 404 dalam fungsi panggilan balik; Daftar 11 menunjukkan fungsi panggilan balik sederhana.
Listing 11. Memeriksa apakah URL ada
function updatePage() {
if (permintaan.readyState == 4) {
if (permintaan.status == 200) {
alert("URL ada");
} else if (permintaan.status == 404) {
alert("URL tidak ada.");
} kalau tidak {
alert("Statusnya adalah: " + permintaan.status);
}
}
}
Sejujurnya, nilai kode ini tidak terlalu bagus. Server harus merespons permintaan dan membuat respons untuk mengisi header respons Content-Length, sehingga tidak ada waktu pemrosesan yang dihemat. Selain itu, ini membutuhkan waktu yang sama lamanya dengan membuat permintaan dan menggunakan permintaan HEAD untuk melihat apakah URL tersebut ada, karena ini menghasilkan permintaan menggunakan GET atau POST daripada hanya menangani kode kesalahan seperti yang ditunjukkan pada Listing 7 . Namun, terkadang berguna untuk mengetahui secara pasti apa yang tersedia saat ini; Anda tidak pernah tahu kapan kreativitas Anda akan muncul atau kapan Anda memerlukan permintaan HEAD!
Permintaan HEAD yang berguna
Salah satu area di mana Anda mungkin menemukan permintaan HEAD sangat berguna adalah untuk melihat panjang konten atau jenis konten. Hal ini dapat menentukan apakah sejumlah besar data perlu dikirim kembali untuk menangani permintaan, dan apakah server mencoba mengembalikan data biner, bukan HTML, teks, atau XML (ketiga jenis data tersebut lebih mudah diproses dalam JavaScript daripada data biner).
Dalam kasus ini, Anda cukup menggunakan nama header yang sesuai dan meneruskannya ke metode getResponseHeader() objek XMLHttpRequest. Jadi untuk mengetahui panjang responnya, panggil saja request.getResponseHeader("Content-Length");. Untuk mendapatkan tipe konten, gunakan request.getResponseHeader("Content-Type");.
Dalam banyak aplikasi, membuat permintaan HEAD tidak menambah fungsionalitas dan bahkan dapat menyebabkan permintaan menjadi lebih lambat (dengan memaksa permintaan HEAD untuk mendapatkan data tentang respons, dan kemudian menggunakan permintaan GET atau POST untuk benar-benar mendapatkan respons). Namun, dalam situasi di mana Anda tidak yakin tentang skrip atau komponen sisi server, menggunakan permintaan HEAD dapat memperoleh beberapa data dasar tanpa benar-benar memproses data respons atau memerlukan banyak bandwidth untuk mengirimkan respons.
Kesimpulan
Bagi banyak programmer Ajax dan Web, materi yang disajikan dalam artikel ini mungkin tampak terlalu maju. Apa gunanya menghasilkan permintaan HEAD? Kapan Anda perlu menangani kode status pengalihan secara eksplisit di JavaScript? Ini adalah pertanyaan bagus; untuk aplikasi sederhana, jawabannya adalah bahwa nilai dari teknik canggih ini tidak terlalu bagus.
Namun, web bukan lagi tempat di mana Anda hanya perlu mengimplementasikan aplikasi sederhana, pengguna menjadi lebih mahir, pelanggan mengharapkan stabilitas yang lebih baik, pelaporan kesalahan yang lebih canggih, dan jika aplikasi tidak berfungsi 1%, maka manajer mungkin dipecat karenanya.
Oleh karena itu, pekerjaan Anda tidak dapat dibatasi pada aplikasi sederhana, namun memerlukan pemahaman yang lebih mendalam tentang XMLHttpRequest.
·Jika Anda dapat memikirkan berbagai status kesiapan—dan memahami perbedaan status kesiapan antar browser—Anda dapat dengan cepat melakukan debug pada aplikasi Anda. Anda bahkan dapat mengembangkan beberapa fungsi kreatif berdasarkan status kesiapan dan melaporkan kembali status yang diminta kepada pengguna dan pelanggan.
·Jika Anda ingin mengontrol kode status, Anda dapat mengatur aplikasi Anda untuk menangani kesalahan skrip, respons yang tidak terduga, dan kasus edge. Hasilnya adalah aplikasi yang bekerja dengan benar sepanjang waktu, tidak hanya ketika semuanya baik-baik saja.
·Tambahkan kemampuan untuk menghasilkan permintaan HEAD, periksa apakah URL ada, dan konfirmasi apakah file telah dimodifikasi, untuk memastikan bahwa pengguna dapat memperoleh halaman yang valid dan informasi yang dilihat pengguna adalah yang terbaru (Yang terpenting) mengejutkan mereka betapa kuat dan serbagunanya aplikasi ini.
Tujuan artikel ini bukan untuk membuat aplikasi Anda terlihat mewah, tetapi untuk membantu Anda menghilangkan sorotan kuning dan menonjolkan keindahan teks, atau agar lebih terlihat seperti desktop. Meskipun ini semua adalah fitur Ajax (yang akan dibahas dalam beberapa artikel berikutnya), semuanya seperti lapisan krim pada kue. Jika Anda dapat menggunakan Ajax untuk membangun fondasi yang kokoh sehingga aplikasi Anda dapat menangani kesalahan dan masalah dengan baik, pengguna akan kembali lagi ke situs dan aplikasi Anda. Di artikel berikutnya, kami akan menambahkan teknik intuitif yang akan membuat pelanggan Anda gemetar karena kegembiraan. (Serius, Anda tidak ingin ketinggalan artikel berikutnya!)