ข้อผิดพลาดทั่วไปของ API และวิธีแก้ไข

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

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

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

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

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

อาจมีข้อผิดพลาด API ที่แตกต่างกัน และที่นี่เราจะบอกคุณเพิ่มเติมเกี่ยวกับ 5 ข้อผิดพลาดที่ได้รับความนิยมมากที่สุด: 

วิธี HTTP ไม่ถูกต้อง

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

ใช้โปรโตคอลที่ไม่ถูกต้อง

ข้อผิดพลาดทั่วไปอีกประการหนึ่งคือความคลาดเคลื่อนระหว่างโปรโตคอล https:// และ http:// API บางตัวอาจสนับสนุนเพียงหนึ่งโปรโตคอลเท่านั้น สมมติว่า http ดังนั้นการระบุ https:// ในกรณีดังกล่าวจะนำไปสู่การประมวลผลคำขอที่ไม่ถูกต้อง แม้ว่าทั้งสองจะได้รับการสนับสนุน แต่ก็อาจมีปัญหากับการเปลี่ยนเส้นทางไปที่ https:// เมื่อคุณระบุ http:// กรณีนี้อาจเกิดขึ้นเมื่อผู้ให้บริการของ API บุคคลที่สามที่คุณวางแผนที่จะใช้ทำการเปลี่ยนแปลงบางอย่างและไม่สามารถส่งการแจ้งเตือนเกี่ยวกับเรื่องนั้นได้ ดังนั้นจึงควรตรวจสอบประเด็นเหล่านี้อีกครั้งเป็นครั้งคราว สำหรับการสร้าง API ของคุณเอง ควรใช้โปรโตคอล https:// เพื่อให้เป็นไปได้ จำเป็นต้องติดตั้งใบรับรอง SSLให้กับเจ้าภาพ เมื่อก่อน ใบรับรอง SSL มีราคาแพงเล็กน้อย ดังนั้นจึงอาจมีข้อสงสัย แต่สำหรับผู้ให้บริการฟรีเช่น Letsencrypt หรือ Cloudflare จะกลายเป็นเรื่องง่ายกว่าที่เคย

ไม่มีข้อความแสดงข้อผิดพลาดที่มีความหมาย

หากคุณเคยเจอ " ข้อผิดพลาด API ที่ไม่คาดคิด” คุณรู้ว่าสิ่งนี้น่ารำคาญแค่ไหน โดยปกติ ข้อความแสดงข้อผิดพลาดควรจะช่วยอำนวยความสะดวกในการแก้ไขปัญหาสำหรับนักพัฒนา โดยจะชี้ให้เห็นถึงสาเหตุที่แท้จริงของข้อผิดพลาด หรืออย่างน้อยต้องค้นหาจากที่ใด น่าเสียดาย ข้อผิดพลาดที่ไม่ให้ข้อมูลดังกล่าวอาจส่งผลให้เสียเวลาหลายชั่วโมง เพิ่มเวลาที่จำเป็นในการแก้ไขข้อผิดพลาด และทำให้ความคิดเห็นเชิงลบที่คุณได้รับพุ่งสูงขึ้นมากขึ้น ด้วยเหตุนี้จึงควรใช้เวลามากขึ้นเล็กน้อยในการอธิบายศักยภาพ ข้อผิดพลาดและทำให้ข้อความเป็นข้อมูลสำหรับผู้ที่จะต้องแก้ไขปัญหา แม้ว่าจะมีรหัสข้อผิดพลาด HTTP อยู่หลายสิบรหัส แต่ก็ไม่จำเป็นต้องใช้ทั้งหมด แต่ให้เก็บรหัสข้อผิดพลาดมาตรฐานไว้ (200,400 และ 500) และพิจารณารวมคำแนะนำไว้ในข้อความเพื่อที่ว่าแม้ในกรณีที่บางอย่างไม่ทำงาน

ปัญหาการอนุญาต

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

ไม่สามารถระบุส่วนหัวของประเภทเนื้อหาและยอมรับ

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

สรุป

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