การพัฒนา API เป็นส่วนสำคัญส่วนหนึ่งของโปรเจ็กต์เว็บแอปส่วนใหญ่ของเรา API (Application Programming Interface) ต้องกำหนดรายละเอียดทางเทคนิคว่าโมดูลอินเทอร์เฟซผู้ใช้โต้ตอบกับโมดูลอินเทอร์เฟซข้อมูลอย่างไร ทำให้เกิดการไหลของข้อมูลระหว่างเว็บเบราว์เซอร์และฐานข้อมูล ในบริบทนี้ การพัฒนา API ครอบคลุมมากกว่าแค่อินเทอร์เฟซ แต่ยังรวมถึงแอปพลิเคชันฝั่งเซิร์ฟเวอร์ที่ทำงานอยู่เบื้องหลัง API อีกด้วย ประโยชน์หลักประการหนึ่งของโครงสร้างโมดูลาร์นี้คือ API เดียวกันสามารถให้บริการไคลเอนต์หลายราย ไม่เพียงแต่ UI ของเบราว์เซอร์เท่านั้น แต่ยังรวมถึงแอปมือถือและแอป IoT อีกด้วย
จากมุมมองของผู้จัดการโครงการ โมดูล API สามารถพัฒนาได้โดยอิสระจากแอปพลิเคชั่นไคลเอนต์ โดยนักพัฒนาที่มีความเชี่ยวชาญด้านเทคโนโลยีแบ็กเอนด์ เช่น วิศวกร PHP นอกจากนี้ นักพัฒนาแอปของลูกค้า ยังมีบทบาทในการกำหนดข้อกำหนดสำหรับ API และทดสอบ API ในที่สุด
การแยกความกังวล
หลักการพื้นฐานประการหนึ่งในการออกแบบซอฟต์แวร์คือ การแยกส่วนปัญหา ที่แบ่งโค้ดแอปพลิเคชันออกเป็นโมดูลที่ไม่มีความรับผิดชอบที่ทับซ้อนกัน ตัวอย่างเช่น API มีหน้าที่ในการค้นหาข้อมูลในฐานข้อมูล ในขณะที่โมดูลการนำเสนอมีหน้าที่ในการแสดงข้อมูลให้ผู้ใช้เห็น การแยกส่วนแบบนี้จะสมเหตุสมผลมากเมื่อมีการแชร์ข้อมูลผู้ใช้และแอปพลิเคชันเดียวกันระหว่างลูกค้าหลายราย เช่น Android iPhone และเว็ปเเอปพลิเคชั่นที่ทำงานในเบราว์เซอร์ จากมุมมองด้านความปลอดภัย การแยกส่วนนี้จะเพิ่มชั้นความปลอดภัยอีกชั้นหนึ่งให้กับระบบ เมื่อแอปฝั่งลูกค้าไม่ได้เชื่อมต่อกับฐานข้อมูลโดยตรง แอปก็ไม่จำเป็นต้องกังวลเกี่ยวกับการรักษาความปลอดภัยข้อมูลประจำตัวของฐานข้อมูลอีกต่อไป
การแบ่งแยกความรับผิดชอบระหว่าง API และแอปไคลเอนต์นั้นไม่ชัดเจนเสมอไป ตัวอย่างเช่น การจัดรูปแบบไทม์สแตมป์เป็นนิพจน์วันที่ที่มนุษย์สามารถอ่านได้นั้นเป็นการดำเนินการที่ทั้งเซิร์ฟเวอร์ API และเบราว์เซอร์ไคลเอนต์สามารถดำเนินการได้ ในกรณีดังกล่าว ปัจจัยเฉพาะของแอปพลิเคชันจะกำหนดว่าใครจะเป็นผู้รับผิดชอบ
บางครั้งการแยกส่วนก็เกิดขึ้นจนสุดทาง ทำให้ไม่เพียงแต่นักพัฒนาในแผนกเดียวกันจะสามารถพัฒนา API และไคลเอนต์ได้เท่านั้น แต่ยังพัฒนาโดยองค์กรที่แยกจากกันได้อีกด้วย เว็บไซต์ของ Ecotrade เป็นตัวอย่างล่าสุดที่ Outsourcify รับผิดชอบ API เว็บ ในขณะที่แอพมือถือได้รับการพัฒนาในยุโรป
มุมมองด้านเทคนิค
จากมุมมองทางเทคนิค แอปพลิเคชันไคลเอนต์จะมอง API เป็นชุดของจุดสิ้นสุดที่ยอมรับคำขอ HTTP และส่งกลับการตอบสนอง HTTP โดยจุดสิ้นสุดจะถูกกำหนดโดยวิธี HTTP และ URL ตัวอย่างเช่น การส่งคำขอไปยังจุดสิ้นสุด “GET /blog/posts” จะส่งกลับบล็อกเป็นการตอบสนอง ในขณะที่การส่งคำขอไปยังจุดสิ้นสุด “POST /blog/posts” จะสร้างทรัพยากรใหม่บนเซิร์ฟเวอร์
สำหรับจุดสิ้นสุดแต่ละจุด API จะกำหนดว่าต้องการอะไรจากคำขอและคำตอบคืออะไร ข้อกำหนดทั่วไปคือโครงสร้างของข้อมูลที่ส่งในเนื้อหาคำขอ เช่น บล็อกต้องมีชื่อเรื่อง ข้อกำหนดทางเทคนิคสำหรับส่วนหัว HTTP ที่สำคัญไม่แพ้กันคือข้อกำหนดที่ระบุได้ว่าเนื้อหาต้องอยู่ในรูปแบบ JSON คำขอต้องได้รับอนุญาตจาก API และแหล่งที่มาของคำขอต้องอยู่ในรายการที่อนุญาตของ API
ไคลเอ็นต์ของ API ยังต้องทราบด้วยว่าการตอบสนองมีลักษณะอย่างไรเพื่อให้สามารถประมวลผลได้อย่างเหมาะสม ซึ่งรวมถึงการตอบสนองที่คาดว่าจะ “ดำเนินการสำเร็จ” พร้อมข้อมูล และการตอบสนองที่ไม่คาดคิดพร้อมข้อความแสดงข้อผิดพลาด
API ภายนอกคืออะไร?
API ภายนอกนั้นมีความคล้ายคลึงกับ API ฝั่งเซิร์ฟเวอร์ในทางเทคนิคที่ให้ข้อมูลแอปพลิเคชันสำหรับอินเทอร์เฟซผู้ใช้ โดยสามารถเข้าถึงได้ผ่านชุด URL ที่ยอมรับคำขอจากแอปพลิเคชันไคลเอนต์ที่ทำงานบนเว็บเซิร์ฟเวอร์หรือเว็บเบราว์เซอร์ API เหล่านี้ได้รับการจัดการและดูแลโดยบุคคลที่สามซึ่งอนุญาตให้เข้าถึงทรัพยากรของตนได้อย่างปลอดภัย ตัวอย่างเช่น สามารถเข้าถึงข้อมูล Google Maps ได้ผ่าน API ที่แตกต่างกันหลายตัว เช่น Roads API, Directions API, Places API เป็นต้น การเข้าถึงต้องใช้ คีย์การเข้าถึง ที่จัดเตรียมโดยเจ้าของทรัพยากรและผู้ให้บริการอย่าง Google เพื่อให้พวกเขาสามารถตรวจสอบคำขอแต่ละรายการและตรวจสอบการใช้งานโดยไคลเอนต์แต่ละราย
การเข้าถึง API ภายนอกนั้นไม่ฟรีเสมอไปและไม่ค่อยมีแบบไม่จำกัด โดยปกติแล้วรหัสการเข้าถึงจะมีระยะเวลาใช้งานซึ่งอาจเชื่อมโยงกับการเป็นสมาชิกหรือการสมัครสมาชิกพร้อมแผนการเรียกเก็บเงิน ผู้ให้บริการยังมีสิทธิ์ที่จะยกเลิกบริการของตนด้วยเหตุผลใดๆ ก็ได้และเมื่อใดก็ได้โดยไม่ต้องรับผิดชอบใดๆ เช่นเดียวกับที่ Google ได้ทำไปแล้วกับ PaLM API ของพวกเขา
ดังนั้นข้อตกลงระดับการบริการจึงถือเป็นสิ่งที่ดีเมื่อต้องชำระเงินสำหรับการเข้าถึง API ภายนอก
ข้อผิดพลาด API และการแก้ไขปัญหา
กิจกรรมต่างๆ ของเราบนเว็บไซต์อาจหยุดชะงักเนื่องจากมีบางอย่างผิดพลาดกับ API เราอาจเห็นไอคอนโหลดที่ไม่หยุดนิ่งหาก API ไม่ตอบสนองตามปกติ หรือข้อมูลบางส่วนอาจหายไปโดยสิ้นเชิงหาก API ไม่สามารถส่งข้อมูลดังกล่าวไปยังอินเทอร์เฟซผู้ใช้ได้ แม้ว่าแอปพลิเคชันไคลเอนต์ที่ใช้งานได้ดีจะสามารถจัดการทุกกรณีที่ API ทำงานผิดปกติหรือไม่สามารถเข้าถึงได้ แต่ก็ไม่สามารถกู้คืนข้อมูลที่หายไปได้ ตัวอย่างเช่น หาก API ไม่สามารถเข้าถึงฐานข้อมูลและตรวจสอบผู้ใช้ได้ เราก็จะต้องติดอยู่กับกล่องโต้ตอบการลองใหม่อีกครั้งของอินเทอร์เฟซผู้ใช้
ขั้นตอนแรกในการจัดการข้อยกเว้นคือการใช้การจัดการข้อผิดพลาดสำหรับข้อผิดพลาด API ที่เป็นไปได้ทั้งหมด เพื่อให้แอปพลิเคชันไคลเอนต์ตอบสนองได้และสามารถแสดงกล่องโต้ตอบอีกครั้งได้ ประการที่สอง เราต้องการบันทึกข้อยกเว้นทั้งหมดบนเซิร์ฟเวอร์ด้วยข้อมูลที่เพียงพอเพื่อให้นักพัฒนาทราบวิธีป้องกันไม่ให้เกิดข้อผิดพลาดในอนาคต ไม่เพียงแต่ด้วยการแก้ไขข้อบกพร่องเท่านั้น แต่ยังรวมถึงการใช้กลไกการกู้คืนสำหรับกรณีที่เซิร์ฟเวอร์ต้นทาง เช่น เซิร์ฟเวอร์ฐานข้อมูล พบข้อผิดพลาดหรือไม่สามารถเข้าถึงได้ ในท้ายที่สุดเเล้ว เราต้องบันทึกพฤติกรรมของ API เพื่อให้ข้อผิดพลาดที่กู้คืนไม่ได้ดูเหมือนเป็นคุณลักษณะ ไม่ใช่ข้อบกพร่อง
API ภายนอกมักจะแข็งแกร่งและเสถียรกว่า API ของแบ็กเอนด์เว็บเเอปพลิเคชั่น ที่เราพัฒนาขึ้นใหม่ แต่สิ่งที่ไม่คาดคิดก็ยังคงเกิดขึ้น สาเหตุที่เป็นไปได้ ได้แก่ การเปลี่ยนแปลงใน API ภายนอก การใช้งานเกินโควตา และการหมดอายุของคีย์การเข้าถึง ผู้ให้บริการส่วนใหญ่ให้เราเข้าถึงคอนโซลนักพัฒนาหรือแดชบอร์ดซึ่งเราจะสามารถดูการใช้งานคีย์การเข้าถึง รวมถึงสถิติเกี่ยวกับคำขอที่ไม่ดี การตอบสนองต่อความล้มเหลว และบันทึกกิจกรรมและข้อผิดพลาด การแก้ไขปัญหาจะง่ายขึ้นมากเมื่อข้อผิดพลาดที่บันทึกไว้จะทริกเกอร์การแจ้งเตือนที่เชื่อมโยงกับเอกสารที่เกี่ยวข้อง
เทคโนโลยี
การนำ API ไปใช้งานจริงในทางเทคนิคสำหรับไคลเอนต์เว็บแอปพลิเคชั่น ไม่จำเป็นต้องมีเทคโนโลยี กรอบงาน หรือภาษาการเขียนโปรแกรมที่เฉพาะเจาะจง ตัวเลือกทั่วไปที่ Outsourcify ประกอบไปด้วยเทคโนโลยีแบ็กเอนด์ยอดนิยมบางส่วน เช่น แอปพลิเคชัน Symfony PHP ที่ให้บริการโดยเซิร์ฟเวอร์เว็บ Apache ที่ทำงานในLinux โปรเจ็กต์จำนวนหนึ่งของเราอาศัย แพลตฟอร์ม API ซึ่งเป็นกรอบงานที่สร้างขึ้นบน Symfony โดยการใส่คำอธิบายประกอบโค้ด PHP ของเรา เราจะกำหนดทรัพยากร API ด้วยการเดินทางไปกลับจากฐานข้อมูลไปยังไคลเอนต์ UI และกลับมา ขั้นตอนการจัดลำดับและการทำให้เป็นมาตรฐานของข้อมูลซึ่งจัดการการแปลงระหว่างข้อมูลเชิงสัมพันธ์ดิบและรูปแบบ JSON ตามลำดับชั้นสามารถปรับแต่งได้โดยใช้ความพยายามเพียงเล็กน้อย ในหลายกรณี วิธีนี้ช่วยลดความจำเป็นในการเขียนโค้ดที่กำหนดเองเพื่อนำการดำเนินการ CRUD พื้นฐานไปใช้กับเอนทิตีทั่วไปของแอปพลิเคชัน ซึ่งจะช่วยเร่งความคืบหน้าของโครงการ คุณสมบัติที่รวมอยู่ในแพลตฟอร์ม API นั้นสามารถกำหนดค่าได้สูง ดังนั้นจึงสามารถปรับแต่งรายละเอียดให้เหมาะกับแอปพลิเคชันและสภาพแวดล้อมต่างๆ ได้
เอกสารประกอบ
นักพัฒนาใช้เอกสาร API (เอกสาร API) เป็นจุดติดต่อบ่อยครั้งกับ API เนื่องจากเอกสารจะตอบคำถามทางเทคนิคทั้งหมดที่นักพัฒนาแอปไคลเอนต์อาจมีเกี่ยวกับ API เมื่อการพัฒนาฝั่งไคลเอนต์แยกจากการพัฒนา API สิ่งสำคัญอย่างยิ่งคือต้องมีข้อกำหนด API ที่ชัดเจนและถูกต้อง เอกสารที่ไม่ถูกต้องหรือไม่สมบูรณ์จะนำไปสู่ความไม่เสถียรในแอปไคลเอนต์ เราไม่สามารถตัดสินใจได้ว่าจะไว้วางใจใคร ระหว่าง API หรือเอกสาร เนื่องจากในอนาคตอาจมีการแก้ไขอย่างใดอย่างหนึ่ง
OpenAPI เป็นรูปแบบมาตรฐานที่ใช้กันทั่วไปในการนำเสนอข้อมูลจำเพาะของจุดสิ้นสุดของ API เอกสารประกอบสามารถสร้างโดยอัตโนมัติจากคำอธิบายประกอบที่รวมอยู่ในโค้ดโปรแกรม สำหรับแต่ละจุดสิ้นสุด เอกสารประกอบ API จะอธิบายโครงสร้างของทั้งคำขอและการตอบสนองในรูปแบบไวยากรณ์ของโครงร่างที่ระบุชื่อ ประเภท และข้อจำกัดการเกิดขึ้นขององค์ประกอบ สามารถรวมคำขอและการตอบสนองตัวอย่างไว้ด้วย
บทสรุป
API เป็นส่วนสำคัญของเว็บแอปพลิเคชัน โดยทำหน้าที่เป็นตัวเชื่อมระหว่างโมดูลต่างๆ API ที่สำคัญที่สุดคือ API ที่ทำงานบนแบ็กเอนด์ของเว็บเซิร์ฟเวอร์และจัดเตรียมข้อมูลแอปพลิเคชันและความปลอดภัยสำหรับอินเทอร์เฟซผู้ใช้ นอกจากนี้ API แบ็กเอนด์ยังเป็นหน่วยการพัฒนาเดียวในโปรเจ็กต์เว็บแอปพลิเคชันที่ใช้สถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์แบบสองชั้น API ภายนอกช่วยเสริมภาพรวมด้วยฟีเจอร์ที่เปิดใช้งานหรือฟังก์ชันเพิ่มเติม แม้ว่าจะมีราคาหรือข้อจำกัดอยู่เสมอ
