[เรียนรู้ Ajax ในสี่วัน] วันที่สามของการเรียนรู้บทช่วยสอน Ajax คำขอขั้นสูงและการตอบกลับใน Ajax

สำหรับนักพัฒนาเว็บจำนวนมาก การสร้างคำขอแบบธรรมดาและรับการตอบกลับแบบธรรมดาก็เพียงพอแล้ว แต่สำหรับนักพัฒนาที่ต้องการเชี่ยวชาญ Ajax จำเป็นต้องมีความเข้าใจอย่างสมบูรณ์เกี่ยวกับรหัสสถานะ HTTP สถานะพร้อม และอ็อบเจ็กต์ XMLHttpRequest ในบทความนี้ Brett McLaughlin จะแนะนำให้คุณรู้จักกับรหัสสถานะต่างๆ และแสดงให้คุณเห็นว่าเบราว์เซอร์จัดการกับมันอย่างไร เขายังพิจารณาคำขอ HTTP บางส่วนที่ใช้ใน Ajax อีกด้วย

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

ในบทความนี้ ฉันจะเน้นไปที่ส่วนสำคัญสามส่วนของออบเจ็กต์คำขอนี้ตามบทความก่อนหน้านี้:

· สถานะพร้อมใช้ HTTP · รหัสสถานะ HTTP · ประเภทคำขอที่สามารถสร้างได้

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

มาดูสถานะพร้อมใช้ HTTP กันก่อน

เมื่อพิจารณาสถานะพร้อมใช้ HTTP ให้ละเอียดยิ่งขึ้น

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

XMLHttpRequest หรือ XMLHttp: การเปลี่ยนชื่อ

Microsoft™ และ Internet Explorer ใช้ออบเจ็กต์ชื่อ XMLHttp แทนออบเจ็กต์ XMLHttpRequest ซึ่งใช้โดย Mozilla, Opera, Safari และเบราว์เซอร์ส่วนใหญ่ที่ไม่ใช่ของ Microsoft เพื่อความเรียบง่าย ฉันจะเรียกวัตถุทั้งสองว่า XMLHttpRequest ซึ่งสอดคล้องกับทั้งสิ่งที่เราเห็นบนเว็บและความตั้งใจของ Microsoft ในการใช้ XMLHttpRequest เป็นวัตถุคำขอใน Internet Explorer 7.0 (ดูส่วนที่ 2 สำหรับข้อมูลเพิ่มเติมเกี่ยวกับปัญหานี้)

รายการ 1. การจัดการการตอบสนองของเซิร์ฟเวอร์ใน

ฟังก์ชันการเรียกกลับ updatePage() {
ถ้า (request.readyState == 4) {
ถ้า (request.status == 200) {
การตอบสนอง var = request.responseText.split("|");
document.getElementById("สั่งซื้อ").value = การตอบสนอง[0];
document.getElementById("ที่อยู่").innerHTML =
การตอบสนอง[1].แทนที่(/n/g, "<br />");
} อื่น
alert("สถานะคือ" + request.status);
-
}

เห็นได้ชัดว่านี่คือการใช้สถานะพร้อมที่พบบ่อยที่สุด (และง่ายที่สุด) ดังที่คุณทราบได้จากหมายเลข "4" มีสถานะพร้อมอื่นๆ อีกหลายสถานะ (คุณเห็นรายการนี้ในบทความที่แล้วด้วย - ดูแหล่งข้อมูล):

· 0: คำขอยังไม่เริ่มต้น ( open() ยังไม่ได้ถูกเรียก) .
·1: คำขอได้ถูกสร้างขึ้นแล้ว แต่ยังไม่ได้ส่ง (send() ยังไม่ได้ถูกเรียก)
·2: คำขอถูกส่งไปแล้วและกำลังดำเนินการ (โดยปกติแล้ว ส่วนหัวของเนื้อหาสามารถรับได้จากการตอบกลับแล้ว)
· 3: กำลังประมวลผลคำขอ โดยปกติแล้วข้อมูลบางส่วนจะพร้อมใช้งานในการตอบกลับ แต่เซิร์ฟเวอร์ยังสร้างการตอบกลับไม่เสร็จสมบูรณ์
· 4: การตอบกลับเสร็จสมบูรณ์ คุณสามารถรับและใช้การตอบกลับของเซิร์ฟเวอร์ได้

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

สถานะพร้อมที่ซ่อนอยู่

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

แต่เพื่อความสนใจของเรา โปรดดูรายการ 2 ซึ่งแสดงวิธีรับสถานะพร้อมเมื่อตั้งค่า readyState เป็น 0

รายการ 2. รับ 0 สถานะพร้อม

ฟังก์ชัน getSalesData() {
//สร้างวัตถุคำขอ
createRequest();
alert("สถานะพร้อมคือ: " + request.readyState);

// ตั้งค่า (เริ่มต้น) คำขอ
var url = "/บอร์ด/เซิร์ฟเล็ต/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = อัพเดตเพจ;
คำขอส่ง (null);
}

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

รูปที่ 1. สถานะพร้อม 0

แน่นอนว่าสิ่งนี้ไม่ได้ช่วยอะไรคุณมากนัก มีบางสถานการณ์ที่คุณต้องแน่ใจว่ายังไม่ได้เรียกใช้ฟังก์ชัน open() ในโลกแห่งความเป็นจริงของการเขียนโปรแกรม Ajax ส่วนใหญ่ การใช้สถานะพร้อมใช้งานเพียงอย่างเดียวคือการใช้ออบเจ็กต์ XMLHttpRequest เดียวกันเพื่อสร้างคำขอหลายรายการในหลายฟังก์ชัน ในกรณีนี้ (ไม่ปกติ) คุณอาจต้องการตรวจสอบให้แน่ใจว่าออบเจ็กต์คำขออยู่ในสถานะที่ไม่ได้เตรียมใช้งาน (readyState == 0) ก่อนที่จะสร้างคำขอใหม่ สิ่งนี้ทำให้แน่ใจได้ว่าฟังก์ชันอื่นไม่ได้ใช้วัตถุในเวลาเดียวกัน

ดูสถานะความพร้อมของคำขอที่กำลังประมวลผล

นอกเหนือจากสถานะพร้อม 0 แล้ว ออบเจ็กต์คำขอยังต้องผ่านสถานะพร้อมอื่น ๆ ของคำขอและการตอบกลับทั่วไป และสุดท้ายจะสิ้นสุดในรูปแบบของสถานะพร้อม 4 นี่คือสาเหตุที่คุณเห็นบรรทัด if (request.readyState == 4) ในฟังก์ชันการติดต่อกลับส่วนใหญ่ ช่วยให้มั่นใจได้ว่าเซิร์ฟเวอร์ประมวลผลคำขอเสร็จแล้ว และตอนนี้ก็ปลอดภัยแล้วที่จะอัปเดตหน้าเว็บหรืออัปเดตหน้าเว็บตามคำขอที่ส่งคืน จากข้อมูลเซิร์ฟเวอร์เพื่อดำเนินการ

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

เมื่อ 0 เท่ากับ 4

คุณต้องตรวจสอบสถานะพร้อมเป็น 0 เพื่อให้แน่ใจว่าออบเจ็กต์คำขอไม่ได้ใช้งานเมื่อฟังก์ชัน JavaScript หลายรายการใช้ออบเจ็กต์คำขอเดียวกัน กลไกนี้อาจทำให้เกิดปัญหาได้ เนื่องจาก readyState == 4 แสดงถึงคำขอที่เสร็จสมบูรณ์ คุณมักจะพบว่าออบเจ็กต์คำขอในสถานะพร้อมซึ่งไม่ได้ใช้งานอยู่ยังคงตั้งค่าเป็น 4 เนื่องจากข้อมูลที่ส่งคืนจากเซิร์ฟเวอร์ถูกใช้ไปแล้ว แต่ไม่มี มีการเปลี่ยนแปลงตั้งแต่ถูกตั้งค่าเป็นสถานะพร้อม มีฟังก์ชัน abort() ที่รีเซ็ตอ็อบเจ็กต์คำขอ แต่ฟังก์ชันนี้ไม่ได้ใช้เพื่อจุดประสงค์นี้จริงๆ หากคุณต้องใช้หลายฟังก์ชัน จะเป็นการดีกว่าถ้าสร้างและใช้ฟังก์ชันเดียวสำหรับแต่ละฟังก์ชัน แทนที่จะใช้วัตถุเดียวกันร่วมกันระหว่างหลายฟังก์ชัน

รายการ 3. ดู

ฟังก์ชันความพร้อม updatePage() {
// ส่งออกสถานะพร้อมปัจจุบัน
alert("updatePage() เรียกด้วยสถานะพร้อมเป็น " + request.readyState);
}

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

รหัสนี้แสดงให้เห็นอย่างชัดเจนถึงความหมายของ onreadystatechange - ทุกครั้งที่สถานะพร้อมของคำขอเปลี่ยนแปลง ระบบจะเรียก updatePage() จากนั้นเราจะเห็นคำเตือน รูปที่ 2 แสดงตัวอย่างการเรียกใช้ฟังก์ชันนี้ โดยสถานะพร้อมคือ 1

รูปที่ 2 สถานะพร้อม 1

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

ความไม่สอดคล้องกันของเบราว์เซอร์

หลังจากที่คุณมีความเข้าใจพื้นฐานเกี่ยวกับกระบวนการแล้ว ให้ลองเข้าถึงเพจของคุณจากเบราว์เซอร์ที่แตกต่างกันสองสามตัว คุณควรสังเกตว่าเบราว์เซอร์ไม่สอดคล้องกันในการจัดการกับสถานะพร้อมใช้งานเหล่านี้ ตัวอย่างเช่น ใน Firefox 1.5 คุณจะเห็นสถานะพร้อมดังต่อไปนี้:

·1
·2
·3
·4

ไม่น่าแปลกใจเลยเนื่องจากสถานะคำขอแต่ละรายการจะแสดงที่นี่ อย่างไรก็ตาม หากคุณใช้ Safari เพื่อเข้าถึงแอปพลิเคชันเดียวกัน คุณควรเห็นสิ่งที่น่าสนใจหรือไม่ก็ได้ หน้าตาใน Safari 2.0.1 มีดังนี้:

·2
·3
·4

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

ตัวอย่างเช่น เมื่อใช้ Opera 8.5 สถานะความพร้อมที่แสดงจะยิ่งแย่ลงไปอีก:

·3
·

4ในที่สุด Internet Explorer จะแสดงสถานะต่อไปนี้:

·1
·2
·3
·4

หากคุณมีปัญหากับคำขอของคุณ นี่คือสถานที่แรกที่จะไปเพื่อระบุปัญหา วิธีที่ดีที่สุดคือทดสอบทั้งใน Internet Explorer และ Firefox คุณจะเห็นสถานะทั้ง 4 สถานะและสามารถตรวจสอบได้ว่าแต่ละสถานะคำขอนั้นอยู่ในสถานะใด

ต่อไปเรามาดูสถานการณ์ในด้านการตอบสนองกัน

ข้อมูลการตอบสนองภายใต้กล้องจุลทรรศน์

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

รายการ 4. การใช้การตอบสนองที่ส่งคืนบนเซิร์ฟเวอร์

ฟังก์ชั่น updatePage() {
ถ้า (request.readyState == 4) {
var newTotal = request.responseText;
var TotalSoldEl = document.getElementById("ขายทั้งหมด");
var netProfitEl = document.getElementById("กำไรสุทธิ");
แทนที่ข้อความ(totalSoldEl, newTotal);

/* รูปภาพกำไรสุทธิใหม่ */
var boardCostEl = document.getElementById("บอร์ด-ต้นทุน");
var boardCost = getText(บอร์ดต้นทุนEl);
var manCostEl = document.getElementById("ต้นทุนคน");
var manCost = getText(manCostEl);
var ProfitPerBoard = ต้นทุนบอร์ด - ต้นทุนคน;
var netProfit =profitPerBoard * newTotal;

/* อัพเดตกำไรสุทธิในแบบฟอร์มการขาย */
netProfit = Math.round(netProfit * 100) / 100;
แทนที่ข้อความ (netProfitEl, netProfit);
รายการ

1 นั้นค่อนข้างง่าย รายการ 4 นั้นซับซ้อนกว่าเล็กน้อย แต่ทั้งคู่จะตรวจสอบสถานะพร้อมตั้งแต่เริ่มต้นและรับค่าของคุณสมบัติ responseText

การดูข้อความตอบกลับของคำขอ

เช่นเดียวกับสถานะพร้อม ค่าของคุณสมบัติ responseText จะเปลี่ยนแปลงตลอดอายุของคำขอด้วย หากต้องการดูการเปลี่ยนแปลงนี้ ให้ใช้รหัสที่แสดงในรายการ 5 เพื่อทดสอบข้อความตอบกลับของคำขอ รวมถึงสถานะความพร้อม

รายการ 5. การทดสอบฟังก์ชันคุณสมบัติ responseText

updatePage() {
// ส่งออกสถานะพร้อมปัจจุบัน
alert("updatePage() ถูกเรียกด้วยสถานะพร้อมเป็น " + request.readyState +
" และข้อความตอบกลับเป็น '" + request.responseText + "'");
}

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

รูปที่ 3 ข้อความตอบกลับสำหรับสถานะพร้อม 2

อย่างไรก็ตาม ในสถานะพร้อม 3 เซิร์ฟเวอร์ได้ใส่ค่าในคุณสมบัติ responseText อย่างน้อยก็ในตัวอย่างนี้ (ดูรูปที่ 4)

รูปที่ 4 ข้อความตอบกลับสำหรับสถานะพร้อม 3

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

การได้รับข้อมูลที่ปลอดภัย

เอกสารและข้อกำหนดทั้งหมดเน้นย้ำว่าข้อมูลจะสามารถใช้ได้อย่างปลอดภัยเมื่อสถานะความพร้อมเป็น 4 เท่านั้น เชื่อฉันเถอะ เมื่อสถานะพร้อมคือ 3 คุณจะไม่ค่อยพบสถานการณ์ที่คุณไม่สามารถรับข้อมูลจากคุณสมบัติ responseText ได้ อย่างไรก็ตาม ไม่ใช่ความคิดที่ดีที่จะสร้างตรรกะของคุณเองในแอปพลิเคชันของคุณโดยขึ้นอยู่กับสถานะพร้อม 3 - เมื่อคุณเขียนโค้ดที่อาศัยข้อมูลที่สมบูรณ์ในสถานะพร้อม 3 คุณเกือบจะรับผิดชอบต่อข้อมูลที่ไม่สมบูรณ์ในขณะนั้น

แนวทางที่ดีกว่าคือการให้ข้อเสนอแนะแก่ผู้ใช้ว่าเมื่ออยู่ในสถานะพร้อม 3 การตอบสนองจะเกิดขึ้นในไม่ช้า แม้ว่าการใช้ฟังก์ชันเช่น alert() จะเป็นความคิดที่ไม่ดีอย่างเห็นได้ชัด แต่การใช้ Ajax แล้วบล็อกผู้ใช้ด้วยกล่องโต้ตอบการแจ้งเตือนนั้นผิดอย่างเห็นได้ชัด คุณสามารถอัปเดตฟิลด์ในแบบฟอร์มหรือเพจได้เมื่อสถานะพร้อมเปลี่ยนแปลง ตัวอย่างเช่น สำหรับสถานะพร้อม 1 ให้ตั้งค่าความกว้างของตัวบ่งชี้ความคืบหน้าเป็น 25% สำหรับสถานะพร้อม 2 ให้ตั้งค่าความกว้างของตัวบ่งชี้ความคืบหน้าเป็น 50% และสำหรับสถานะพร้อม 3 ให้ตั้งค่าความกว้างของตัวบ่งชี้ความคืบหน้าเป็น 25 % ความกว้างถูกตั้งค่าเป็น 75% และเมื่อสถานะพร้อมเป็น 4 ความกว้างของตัวบ่งชี้ความคืบหน้าจะถูกตั้งค่าเป็น 100% (เสร็จสมบูรณ์)

แน่นอนว่าตามที่คุณได้เห็นแล้วว่าวิธีนี้ฉลาดมาก แต่ก็ขึ้นอยู่กับเบราว์เซอร์ บน Opera คุณจะไม่เห็นสถานะพร้อมใช้สองสถานะแรก และใน Safari จะไม่มีสถานะแรก (1) ด้วยเหตุนี้ ฉันจึงทิ้งโค้ดนี้ไว้เป็นแบบฝึกหัด และไม่ได้รวมไว้ในบทความนี้

ตอนนี้ได้เวลาดูรหัสสถานะแล้ว

เจาะลึกรหัสสถานะ HTTP

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

· 401: ไม่ได้รับอนุญาต · 403: ต้องห้าม · 404: ไม่พบ

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

200: ทุกอย่างเรียบร้อยดี

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

รายการ 6. ฟังก์ชั่นการโทรกลับที่ละเว้นฟังก์ชันรหัสสถานะ

updatePage() {
ถ้า (request.readyState == 4) {
การตอบสนอง var = request.responseText.split("|");
document.getElementById("สั่งซื้อ").value = การตอบสนอง[0];
document.getElementById("ที่อยู่").innerHTML =
การตอบสนอง[1].แทนที่(/n/g, "<br />");
-
}

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

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

รายการ 7. ตรวจสอบฟังก์ชันรหัสสถานะที่ถูกต้อง

updatePage() {
ถ้า (request.readyState == 4) {
ถ้า (request.status == 200) {
การตอบสนอง var = request.responseText.split("|");
document.getElementById("สั่งซื้อ").value = การตอบสนอง[0];
document.getElementById("ที่อยู่").innerHTML =
การตอบสนอง[1].แทนที่(/n/g, "<br />");
} อื่น
alert("สถานะคือ" + request.status);
-
}

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

การเปลี่ยนเส้นทางและการเปลี่ยนเส้นทาง

ก่อนที่เราจะลงรายละเอียดเกี่ยวกับข้อผิดพลาด เราควรพูดคุยถึงปัญหาที่คุณไม่ต้องกังวลเมื่อใช้ Ajax - การเปลี่ยนเส้นทาง ในบรรดารหัสสถานะ HTTP นี่คือรหัสสถานะ 300 ชุด ซึ่งรวมถึง:

301: ย้ายอย่างถาวร 302: พบ (คำขอเปลี่ยนเส้นทางไปยัง URL/URI อื่น)
·305: การใช้พรอกซี (คำขอต้องใช้พร็อกซีเพื่อเข้าถึงทรัพยากรที่ร้องขอ)

โปรแกรมเมอร์ Ajax อาจไม่กังวลเกี่ยวกับปัญหาการเปลี่ยนเส้นทางมากนัก ด้วยเหตุผลสองประการ:

·ประการแรก แอปพลิเคชัน Ajax มักจะได้รับการออกแบบสำหรับการเขียนสำหรับฝั่งเซิร์ฟเวอร์เฉพาะ สคริปต์ เซิร์ฟเล็ต หรือแอปพลิเคชัน โปรแกรมเมอร์ Ajax มีความชัดเจนน้อยลงเกี่ยวกับส่วนประกอบที่หายไปโดยที่คุณไม่เห็น ดังนั้น บางครั้งคุณทราบว่าทรัพยากรถูกย้ายแล้ว (เนื่องจากคุณย้ายหรือย้ายด้วยวิธีการบางอย่าง) จากนั้นคุณแก้ไข URL ในคำขอและไม่เคยพบผลลัพธ์นี้อีกเลย
เหตุผลที่สำคัญกว่านั้นคือแอปพลิเคชัน Ajax และคำขอถูกห่อหุ้มไว้ในแซนด์บ็อกซ์ ซึ่งหมายความว่าโดเมนที่ให้บริการเว็บเพจที่สร้างคำขอ Ajax จะต้องเป็นโดเมนที่ตอบสนองต่อคำขอเหล่านั้น ดังนั้น เว็บเพจที่ ebay.com จัดให้ไม่สามารถส่งคำขอแบบ Ajax ไปยังสคริปต์ที่ทำงานบน amazon.com ได้ แอปพลิเคชัน Ajax บน ibm.com ไม่สามารถส่งคำขอไปยังเซิร์ฟเล็ตที่ทำงานบน netbeans.org
·ผลลัพธ์ก็คือคำขอของคุณไม่สามารถเปลี่ยนเส้นทางไปยังเซิร์ฟเวอร์อื่นได้โดยไม่สร้างข้อผิดพลาดด้านความปลอดภัย ในกรณีเหล่านี้ คุณจะไม่ได้รับรหัสสถานะเลย โดยปกติแล้วข้อผิดพลาด JavaScript จะถูกสร้างขึ้นในคอนโซลดีบัก ดังนั้น หลังจากที่คิดเกี่ยวกับรหัสสถานะมากพอแล้ว คุณก็สามารถเพิกเฉยต่อปัญหาของรหัสการเปลี่ยนเส้นทางได้เลย

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

ข้อผิดพลาด

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

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

Edge Cases และสถานการณ์ที่ยากลำบาก

ณ จุดนี้ โปรแกรมเมอร์มือใหม่บางคนอาจสงสัยว่ามันเกี่ยวกับอะไร นี่คือข้อเท็จจริงที่คุณจำเป็นต้องรู้: คำขอ Ajax น้อยกว่า 5% ใช้สถานะพร้อม เช่น 2 และ 3 และรหัสสถานะ เช่น 403 (จริงๆ แล้ว อัตรานี้น่าจะใกล้ถึง 1% หรือน้อยกว่านั้นด้วยซ้ำ) สถานการณ์เหล่านี้มีความสำคัญมากและเรียกว่ากรณีขอบ - เกิดขึ้นเฉพาะในสถานการณ์เฉพาะเจาะจงเท่านั้นที่ต้องพบกับปัญหาที่แปลกใหม่ที่สุด แม้ว่าสถานการณ์เหล่านี้จะไม่ธรรมดา แต่กรณี Edge เหล่านี้เป็นสาเหตุถึง 80% ของปัญหาที่ผู้ใช้ส่วนใหญ่พบ!

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

รูปที่ 5 การจัดการข้อผิดพลาดทั่วไป

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

รายการ 8. ตรวจสอบฟังก์ชันรหัสสถานะที่ถูกต้อง

updatePage() {
ถ้า (request.readyState == 4) {
ถ้า (request.status == 200) {
การตอบสนอง var = request.responseText.split("|");
document.getElementById("สั่งซื้อ").value = การตอบสนอง[0];
document.getElementById("ที่อยู่").innerHTML =
การตอบสนอง[1].แทนที่(/n/g, "<br />");
} อื่นถ้า (request.status == 404) {
alert ("ไม่พบ URL ที่ร้องขอ");
} อื่นถ้า (request.status == 403) {
alert("การเข้าถึงถูกปฏิเสธ");
} อื่น
alert("สถานะคือ" + request.status);
-
}

แม้ว่าจะยังค่อนข้างง่าย แต่ก็ให้ข้อมูลที่เป็นประโยชน์มากกว่าเล็กน้อย รูปที่ 6 แสดงข้อผิดพลาดเดียวกันกับรูปที่ 5 แต่คราวนี้รหัสการจัดการข้อผิดพลาดจะอธิบายให้ผู้ใช้หรือโปรแกรมเมอร์เข้าใจได้ดีขึ้นว่าเกิดอะไรขึ้นกันแน่

รูปที่ 6 การจัดการข้อผิดพลาดพิเศษ

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

ประเภทคำขออื่นๆ

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

การร้องขอ

การสร้างคำขอ HEAD นั้นง่ายมาก คุณเรียกเมธอด open() ด้วย "HEAD" (แทนที่จะเป็น "GET" หรือ "POST") เป็นพารามิเตอร์แรก ดังแสดงในรายการที่ 9

รายการ 9. การใช้ Ajax เพื่อสร้างฟังก์ชันคำขอ HEAD

getSalesData() {
createRequest();
var url = "/บอร์ด/เซิร์ฟเล็ต/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = อัพเดตเพจ;
คำขอส่ง (null);
}

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

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

รายการ 10. ส่งออกเนื้อหาของส่วนหัวการตอบสนองที่ได้รับจาก

ฟังก์ชันคำขอ HEAD updatePage() {
ถ้า (request.readyState == 4) {
alert(request.getAllResponseHeaders());
-
}

ดูรูปที่ 7 ซึ่งแสดงส่วนหัวการตอบสนองที่ส่งคืนจากแอปพลิเคชัน Ajax แบบธรรมดาที่สร้างคำขอ HEAD ไปยังเซิร์ฟเวอร์

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

การตรวจสอบ URL

คุณได้เห็นวิธีการตรวจสอบข้อผิดพลาด 404 เมื่อไม่มี URL แล้ว หากกลายเป็นปัญหาทั่วไป - บางทีสคริปต์หรือเซิร์ฟเล็ตบางตัวหายไป - คุณอาจต้องการตรวจสอบ URL ก่อนที่จะทำการร้องขอ GET หรือ POST แบบเต็ม หากต้องการใช้ฟังก์ชันนี้ ให้สร้างคำขอ HEAD แล้วตรวจสอบข้อผิดพลาด 404 ในฟังก์ชันการโทรกลับ รายการ 11 จะแสดงฟังก์ชันการโทรกลับแบบธรรมดา

รายการ 11. ตรวจสอบว่ามี URL อยู่หรือไม่

ฟังก์ชัน updatePage() {
ถ้า (request.readyState == 4) {
ถ้า (request.status == 200) {
alert("มี URL อยู่แล้ว");
} อื่นถ้า (request.status == 404) {
alert("ไม่มี URL");
} อื่น {
alert("สถานะคือ:" + request.status);
-
-
}

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

คำขอ HEAD ที่เป็นประโยชน์

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

ในกรณีเหล่านี้ คุณเพียงใช้ชื่อส่วนหัวที่เหมาะสมและส่งต่อไปยังเมธอด getResponseHeader() ของออบเจ็กต์ XMLHttpRequest ดังนั้นเพื่อให้ได้ความยาวของการตอบกลับ เพียงโทร request.getResponseHeader("Content-Length"); หากต้องการรับประเภทเนื้อหา ให้ใช้ request.getResponseHeader("Content-Type");

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

สำหรับโปรแกรมเมอร์ Ajax และ Web จำนวนมาก เนื้อหาที่นำเสนอในบทความนี้อาจดูสูง

เกินไป

มูลค่าของการสร้างคำขอ HEAD คืออะไร? เมื่อใดที่คุณจำเป็นต้องจัดการรหัสสถานะการเปลี่ยนเส้นทางใน JavaScript อย่างชัดเจน คำถามเหล่านี้เป็นคำถามที่ดี สำหรับการใช้งานทั่วไป คำตอบก็คือคุณค่าของเทคนิคขั้นสูงเหล่านี้ไม่ได้ดีนัก

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

ดังนั้น งานของคุณจึงไม่สามารถจำกัดอยู่เพียงแอปพลิเคชันธรรมดาๆ ได้ แต่ต้องมีความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับ XMLHttpRequest

·หากคุณนึกถึงสถานะความพร้อมต่างๆ ได้ และเข้าใจว่าสถานะความพร้อมเหล่านี้แตกต่างกันอย่างไรในเบราว์เซอร์ คุณจะสามารถดีบักแอปพลิเคชันของคุณได้อย่างรวดเร็ว คุณยังสามารถพัฒนาฟังก์ชันการทำงานเชิงสร้างสรรค์บางอย่างตามสถานะความพร้อม และรายงานสถานะที่ร้องขอกลับไปยังผู้ใช้และลูกค้าได้
·หากคุณต้องการควบคุมรหัสสถานะ คุณสามารถตั้งค่าแอปพลิเคชันของคุณให้จัดการกับข้อผิดพลาดของสคริปต์ การตอบสนองที่ไม่คาดคิด และกรณี Edge ได้ ผลลัพธ์ที่ได้คือแอพพลิเคชั่นที่ทำงานได้อย่างถูกต้องตลอดเวลา ไม่ใช่แค่เมื่อทุกอย่างเรียบร้อยดีเท่านั้น
·เพิ่มความสามารถในการสร้างคำขอ HEAD ตรวจสอบว่ามี URL อยู่หรือไม่ และยืนยันว่าไฟล์ได้รับการแก้ไขหรือไม่ เพื่อให้มั่นใจว่าผู้ใช้สามารถรับหน้าที่ถูกต้องได้ และข้อมูลที่ผู้ใช้เห็นเป็นข้อมูลล่าสุด ( ที่สำคัญที่สุด) ทำให้พวกเขาประหลาดใจ แอปนี้มีความแข็งแกร่งและหลากหลายเพียงใด
จุดประสงค์ของบทความนี้ไม่ใช่เพื่อทำให้แอปพลิเคชันของคุณดูหรูหรา แต่เพื่อช่วยคุณลบสปอตไลท์สีเหลืองและเน้นความสวยงามของข้อความ หรือดูเหมือนเดสก์ท็อปมากขึ้น แม้ว่าสิ่งเหล่านี้จะเป็นคุณสมบัติทั้งหมดของ Ajax (ซึ่งจะกล่าวถึงในบทความถัดไป) แต่ก็เหมือนกับชั้นครีมบนเค้ก หากคุณสามารถใช้ Ajax เพื่อสร้างรากฐานที่มั่นคงเพื่อให้แอปพลิเคชันของคุณสามารถจัดการกับข้อผิดพลาดและปัญหาได้ดี ผู้ใช้จะกลับมาที่ไซต์และแอปพลิเคชันของคุณ ในบทความถัดไป เราจะเพิ่มเทคนิคที่ใช้งานง่ายนี้ซึ่งจะทำให้ลูกค้าของคุณสั่นสะท้านด้วยความตื่นเต้น (อย่างจริงจังคุณไม่ควรพลาดบทความถัดไป!)