10 ข้อผิดพลาดที่พบบ่อยที่สุดที่นักพัฒนาเว็บทำ: บทช่วยสอนสำหรับนักพัฒนา

นับตั้งแต่คำว่า World Wide Web ได้รับการประกาศเกียรติคุณในปี 1990 การพัฒนาแอปพลิเคชันเว็บได้พัฒนาจากการให้บริการหน้า HTML แบบสแตติกไปจนถึงแอปพลิเคชันทางธุรกิจที่ซับซ้อนและไดนามิกโดยสมบูรณ์

วันนี้ เรามีแหล่งข้อมูลดิจิทัลและสิ่งพิมพ์นับพันที่ให้คำแนะนำทีละขั้นตอนเกี่ยวกับการพัฒนาเว็บแอปพลิเคชันต่างๆ ทุกประเภท สภาพแวดล้อมการพัฒนานั้น "ฉลาด" พอที่จะจับและแก้ไขข้อผิดพลาดมากมายที่นักพัฒนาช่วงแรก ๆ ต่อสู้ด้วยเป็นประจำ มีแพลตฟอร์มการพัฒนาที่แตกต่างกันมากมายที่เปลี่ยนหน้า HTML แบบคงที่ธรรมดาให้เป็นแอปพลิเคชันแบบโต้ตอบได้อย่างง่ายดาย

รูปแบบ แนวทางปฏิบัติ และแพลตฟอร์มการพัฒนาทั้งหมดนี้มีพื้นฐานร่วมกัน และล้วนมีแนวโน้มที่จะเกิดปัญหาการพัฒนาเว็บที่คล้ายคลึงกันซึ่งเกิดจากธรรมชาติของแอปพลิเคชันเว็บ

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

ข้อผิดพลาดทั่วไปหมายเลข 1: การตรวจสอบอินพุตที่ไม่สมบูรณ์

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

ผลที่ตามมามากที่สุดอย่างหนึ่งของข้อผิดพลาดนี้คือ SQL Injection ซึ่งอยู่ใน OWASP Top 10 ปีแล้วปีเล่า

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

ข้อผิดพลาดทั่วไปหมายเลข 2: การตรวจสอบสิทธิ์โดยไม่ได้รับอนุญาตอย่างเหมาะสม

ก่อนที่เราจะดำเนินการต่อ ให้ตรวจสอบให้แน่ใจว่าเรามีความสอดคล้องกันในสองคำนี้ ตามที่ระบุไว้ใน 10 ช่องโหว่ด้านความปลอดภัยบนเว็บที่พบบ่อยที่สุด:

การ ตรวจสอบความถูกต้อง: การตรวจสอบว่าบุคคลเป็น (หรืออย่างน้อยก็ดูเหมือนจะเป็น) ผู้ใช้เฉพาะ เนื่องจากเขา/เธอได้ให้ข้อมูลรับรองความปลอดภัยอย่างถูกต้อง (รหัสผ่าน คำตอบสำหรับคำถามเพื่อความปลอดภัย การสแกนลายนิ้วมือ ฯลฯ)

การอนุญาต: การ ยืนยันว่าผู้ใช้รายใดรายหนึ่งมีสิทธิ์เข้าถึงทรัพยากรเฉพาะหรือได้รับอนุญาตให้ดำเนินการบางอย่าง

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

ให้ฉันสาธิตปัญหานี้ด้วยตัวอย่าง:

พิจารณาว่าเบราว์เซอร์ของคุณเก็บข้อมูลผู้ใช้ที่บันทึกไว้ในวัตถุที่คล้ายกับต่อไปนี้:

 { username:'elvis', role:'singer', token:'123456789' }

เมื่อทำการเปลี่ยนรหัสผ่าน แอปพลิเคชันของคุณจะสร้าง POST:

 POST /changepassword/:username/:newpassword

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

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

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

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

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

การ Authentication และ Authorization เป็นสองด้านของเหรียญเดียวกัน อย่าปฏิบัติต่อพวกเขาแยกกัน

ข้อผิดพลาดทั่วไปหมายเลข 3: ไม่พร้อมที่จะปรับขนาด

ในโลกปัจจุบันของการพัฒนาความเร็วสูง ตัวเร่งการเริ่มต้นระบบ และการเข้าถึงแนวคิดที่ยอดเยี่ยมทั่วโลกในทันที การมี MVP (ผลิตภัณฑ์ที่มีประสิทธิภาพขั้นต่ำ) ออกสู่ตลาดโดยเร็วที่สุดเป็นเป้าหมายร่วมกันสำหรับหลายๆ บริษัท

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

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

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

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

ข้อผิดพลาดทั่วไปหมายเลข 4: SEO ผิดหรือหายไป

สาเหตุหลักของแนวทางปฏิบัติที่ดีที่สุดสำหรับ SEO ที่ไม่ถูกต้องหรือขาดหายไปบนเว็บไซต์คือ "ผู้เชี่ยวชาญด้าน SEO" ที่เข้าใจผิด นักพัฒนาเว็บหลายคนเชื่อว่าพวกเขารู้เพียงพอเกี่ยวกับ SEO และไม่ซับซ้อนเป็นพิเศษ แต่ก็ไม่เป็นความจริง ความเชี่ยวชาญ SEO ต้องใช้เวลาอย่างมากในการค้นคว้าแนวทางปฏิบัติที่ดีที่สุดและกฎเกณฑ์ที่เปลี่ยนแปลงตลอดเวลาเกี่ยวกับวิธีการจัดทำดัชนีของ Google, Bing และ Yahoo ของเว็บ เว้นแต่คุณจะทำการทดลองอย่างต่อเนื่องและมีการติดตามและวิเคราะห์ที่แม่นยำ คุณไม่ใช่ผู้เชี่ยวชาญ SEO และคุณไม่ควรอ้างว่าเป็นผู้เชี่ยวชาญ

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

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

ข้อผิดพลาดทั่วไปหมายเลข 5: เวลาหรือการดำเนินการที่ใช้ตัวประมวลผลในตัวจัดการคำขอ

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

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

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

ข้อผิดพลาดทั่วไปหมายเลข 6: ไม่เพิ่มประสิทธิภาพการใช้แบนด์วิดท์

การพัฒนาและการทดสอบส่วนใหญ่เกิดขึ้นในสภาพแวดล้อมเครือข่ายท้องถิ่น ดังนั้นเมื่อคุณดาวน์โหลดภาพพื้นหลัง 5 ภาพโดยแต่ละภาพมีขนาด 3MB ขึ้นไป คุณอาจไม่ได้ระบุปัญหาเกี่ยวกับความเร็วการเชื่อมต่อ 1Gbit ในสภาพแวดล้อมการพัฒนาของคุณ แต่เมื่อผู้ใช้ของคุณเริ่มโหลดโฮมเพจขนาด 15MB ผ่านการเชื่อมต่อ 3G บนสมาร์ทโฟน คุณควรเตรียมตัวสำหรับรายการข้อร้องเรียนและปัญหา

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

1. การย่อขนาด JavaScript ทั้งหมด
2. การลดขนาด CSS ทั้งหมด
3. การบีบอัด HTTP ฝั่งเซิร์ฟเวอร์
4. การเพิ่มประสิทธิภาพของขนาดและความละเอียดของภาพ

ข้อผิดพลาดทั่วไปหมายเลข 7: ไม่พัฒนาสำหรับขนาดหน้าจอที่ต่างกัน

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

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

มีรูปแบบและแนวทางปฏิบัติมากมายสำหรับการสร้างเว็บแอปพลิเคชันที่ตอบสนอง แต่ละแพลตฟอร์มการพัฒนามีคำแนะนำและเคล็ดลับ แต่มีกรอบงานบางอย่างที่ไม่ขึ้นอยู่กับแพลตฟอร์ม ที่นิยมมากที่สุดน่าจะเป็น Twitter Bootstrap เป็นเฟรมเวิร์ก HTML, CSS และ JavaScript แบบโอเพ่นซอร์สและฟรีที่นำมาใช้โดยทุกแพลตฟอร์มการพัฒนาที่สำคัญ เพียงปฏิบัติตามรูปแบบและแนวทางปฏิบัติของ Bootstrap เมื่อสร้างแอปพลิเคชันของคุณ แล้วคุณจะได้รับเว็บแอปพลิเคชันที่ตอบสนองโดยไม่มีปัญหาใดๆ เลย

ข้อผิดพลาดทั่วไปหมายเลข 8: ความเข้ากันไม่ได้ของข้ามเบราว์เซอร์

กระบวนการพัฒนา ในกรณีส่วนใหญ่ อยู่ภายใต้แรงกดดันอย่างหนัก ทุกแอปพลิเคชันจำเป็นต้องได้รับการเผยแพร่โดยเร็วที่สุด และแม้แต่นักพัฒนาเว็บที่ดีก็มักจะเน้นที่การนำเสนอฟังก์ชันการทำงานมากกว่าการออกแบบ แม้ว่านักพัฒนาซอฟต์แวร์ส่วนใหญ่จะติดตั้ง Chrome, Firefox, IE แล้ว พวกเขาใช้เวลาเพียง 90% ของเวลาเหล่านี้เท่านั้น เป็นเรื่องปกติที่จะใช้เบราว์เซอร์หนึ่งตัวในระหว่างการพัฒนา และเช่นเดียวกับที่แอปพลิเคชันใกล้จะเสร็จสมบูรณ์ คุณจะเริ่มทดสอบเบราว์เซอร์อื่นในเบราว์เซอร์อื่น นี่เป็นเหตุผลที่สมเหตุสมผลอย่างยิ่ง สมมติว่าคุณมีเวลามากในการทดสอบและแก้ไขปัญหาที่ปรากฏในขั้นตอนนี้

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

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

ข้อผิดพลาดทั่วไปหมายเลข 9: ไม่ได้วางแผนสำหรับการพกพา

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

การตั้งค่าแอปพลิเคชันที่เหมาะสมควรไม่ต้องบำรุงรักษา:

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

ข้อผิดพลาดทั่วไปหมายเลข 10: RESTful Anti Patterns

RESTful APIs เข้ามาแทนที่การพัฒนาเว็บและพร้อมที่จะอยู่ต่อไป เว็บแอปพลิเคชันเกือบทั้งหมดได้ใช้บริการ REST บางประเภท ไม่ว่าจะเป็นการใช้งานภายในหรือการรวมเข้ากับระบบภายนอก แต่เรายังคงเห็นรูปแบบและบริการ RESTful ที่เสียหายซึ่งไม่เป็นไปตามแนวทางปฏิบัติที่คาดหวัง

ข้อผิดพลาดที่พบบ่อยที่สุดสองข้อที่เกิดขึ้นเมื่อเขียน RESTful API คือ:

1. ใช้กริยา HTTP ที่ไม่ถูกต้อง เช่น การใช้ GET เพื่อเขียนข้อมูล HTTP GET ได้รับการออกแบบมาให้ใช้งานได้จริงและปลอดภัย ซึ่งหมายความว่าไม่ว่าคุณจะเรียกใช้ GET บนทรัพยากรเดียวกันกี่ครั้ง การตอบสนองควรเหมือนเดิมเสมอ และไม่ควรมีการเปลี่ยนแปลงในสถานะแอปพลิเคชัน

2. ไม่ส่งรหัสสถานะ HTTP ที่ถูกต้อง ตัวอย่างที่ดีที่สุดของข้อผิดพลาดนี้คือ การส่งข้อความแสดงข้อผิดพลาดพร้อมรหัสตอบกลับ 200

    HTTP 200 OK { message:'there was an error' }

คุณควรส่ง HTTP 200 ตกลงเมื่อคำขอไม่ได้สร้างข้อผิดพลาดเท่านั้น ในกรณีที่เกิดข้อผิดพลาด คุณควรส่ง 400, 401, 500 หรือรหัสสถานะอื่นใดที่เหมาะสมกับข้อผิดพลาดที่เกิดขึ้น

สามารถดูภาพรวมโดยละเอียดของรหัสสถานะ HTTP มาตรฐานได้ที่นี่

สรุป

การพัฒนาเว็บเป็นคำศัพท์ที่กว้างมากซึ่งสามารถครอบคลุมถึงการพัฒนาเว็บไซต์ บริการเว็บ หรือเว็บแอปพลิเคชันที่ซับซ้อนได้

แนวทางหลักของคู่มือการพัฒนาเว็บฉบับนี้คือการเตือนว่าคุณควรระมัดระวังเกี่ยวกับการรับรองความถูกต้องและการอนุญาต วางแผนสำหรับความสามารถในการปรับขนาด และอย่าด่วนสรุปสิ่งใดๆ หรือพร้อมที่จะจัดการกับรายการปัญหาการพัฒนาเว็บที่ยาวเหยียด!