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