- แนวโน้มของโปรโตคอล API รวมถึงข้อดี/ข้อเสียที่ Postman สรุปจากการสำรวจนักพัฒนา 40,000 คน
- เช่น REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC เป็นต้น
REST
- ยังคงถูกใช้งานอย่างแพร่หลายมากที่สุด แม้จะลดลงจาก 92% เหลือ 86% ในช่วง 2 ปีที่ผ่านมา
- ความเรียบง่าย ความสามารถในการขยายระบบ และความง่ายในการผสานรวมกับเว็บเซอร์วิส
- ข้อดีของ REST
- ความเรียบง่ายและความเป็นมาตรฐาน: ใช้วิธีการ HTTP มาตรฐาน ทำให้นักพัฒนาที่คุ้นเคยกับ HTTP อยู่แล้วนำไปใช้ได้ง่าย ความเรียบง่ายช่วยให้เรียนรู้และผสานรวมได้รวดเร็ว
- ความสามารถในการขยายระบบ: ด้วยคุณสมบัติ stateless ของ REST เซิร์ฟเวอร์จึงไม่จำเป็นต้องเก็บข้อมูล session ระหว่างคำขอ ช่วยให้ขยายระบบในแนวนอนได้ง่ายด้วยการเพิ่มอินสแตนซ์โดยไม่ต้องพึ่งเซิร์ฟเวอร์ที่ใช้ร่วมกัน
- ประสิทธิภาพ: การเป็น stateless และการตอบกลับที่แคชได้ช่วยเพิ่มความเร็วในการทำงานและลดจำนวนคำขอ
- ความเป็นโมดูล: บริการแบบ RESTful สามารถพัฒนาเป็นองค์ประกอบแบบโมดูลได้ ช่วยให้อัปเดตแยกส่วนได้อย่างอิสระและปรับปรุงการดูแลรักษา
- ไม่ยึดติดกับแพลตฟอร์ม: ใช้งานได้กับไคลเอนต์หลากหลายประเภท ความสามารถในการทำงานร่วมกันช่วยส่งเสริมการผสานรวม API ทั่วทั้งระบบ
- เครื่องมือและการสนับสนุนจากชุมชนที่เติบโตเต็มที่: มีเครื่องมือ ไลบรารี แนวปฏิบัติที่ดี คู่มือแก้ปัญหา และทรัพยากรจากชุมชนจำนวนมาก
- ความท้าทายของ REST
- over-fetching และ under-fetching: ไคลเอนต์อาจต้องการข้อมูลเพียงบางส่วน ทำให้ดึงข้อมูลมากเกินไปหรือน้อยเกินไป ซึ่งอาจก่อให้เกิดปัญหาด้านประสิทธิภาพและสิ้นเปลืองแบนด์วิดท์
- หลายอินเทอร์เฟซ: การดึงข้อมูลที่เกี่ยวข้องกันอาจต้องใช้หลายคำขอ ส่งผลให้มี latency เพิ่มขึ้น และเมื่อแอปพลิเคชันขยายตัว การเรียกต่อเนื่องเหล่านี้อาจกลายเป็นปัญหา
- ปัญหาการจัดการเวอร์ชัน: การสร้าง REST API เวอร์ชันใหม่อาจยุ่งยาก โดยเฉพาะเมื่อโครงสร้างข้อมูลหรือความสามารถของบริการเปลี่ยนไป ซึ่งมักทำให้เกิดปัญหาความเข้ากันได้ย้อนหลัง
- ภาระของความเป็น stateless: แม้ stateless จะช่วยด้านการขยายระบบ แต่ก็หมายความว่าทุกคำขอต้องส่งบริบทที่จำเป็นทั้งหมดมาด้วย ซึ่งอาจเพิ่มภาระ โดยเฉพาะเมื่อไคลเอนต์ต้องส่งข้อมูลซ้ำจำนวนมาก
- ขาดความสามารถแบบเรียลไทม์: REST ไม่ได้เหมาะที่สุดสำหรับแอปเรียลไทม์ เช่น แชตหรือไลฟ์ฟีด โดย WebSocket และ SSE เหมาะกับกรณีใช้งานเหล่านี้มากกว่า
WebHooks
- WebHook คือ HTTP callback แบบกำหนดเองที่ถูก trigger โดยเหตุการณ์ในแอปพลิเคชันต้นทาง
- เมื่อเกิดเหตุการณ์ แอปต้นทางจะส่งคำขอ HTTP (โดยทั่วไปคือ POST) ไปยัง URI ที่แอปปลายทางกำหนดไว้ ทำให้สามารถสื่อสารแบบอิงเหตุการณ์ได้เกือบเรียลไทม์โดยไม่ต้อง polling ซ้ำๆ
- WebHook กำลังได้รับความนิยมมากขึ้นเรื่อยๆ โดยมีนักพัฒนา 36% ใช้งานเพื่อการผสานรวมระหว่างระบบต่างๆ อย่างราบรื่น
- ข้อดีของ WebHooks
- การสื่อสารแบบเรียลไทม์: WebHook ช่วยให้ส่งข้อมูลแบบเรียลไทม์ได้ เมื่อเกิดเหตุการณ์ ข้อมูลที่เกี่ยวข้องจะถูกส่งทันที ทำให้มั่นใจได้ว่าระบบต่างๆ จะซิงก์กันเป็นปัจจุบัน
- ประสิทธิภาพ: WebHook ช่วยตัด polling ที่ใช้ทรัพยากรสูงออกไป ทำให้ประหยัดกำลังประมวลผลและแบนด์วิดท์
- ความยืดหยุ่น: WebHook สามารถตั้งค่าให้ตอบสนองต่อเหตุการณ์เฉพาะได้ จึงปรับแต่งได้ว่าการกระทำหรือ trigger แบบใดในแอปหนึ่งจะส่งข้อมูลไปยังอีกแอปหนึ่ง
- การผสานรวมที่ง่ายขึ้น: การใช้วิธีการ HTTP ทำให้แอปพลิเคชันส่วนใหญ่นำไปใช้ได้ง่าย
- รองรับสถาปัตยกรรมแบบแยกส่วน: WebHook ทำงานบนพื้นฐานของเหตุการณ์ จึงรองรับสถาปัตยกรรมแบบ event-driven หรือแบบแยกส่วนได้โดยธรรมชาติ ช่วยเพิ่มความเป็นโมดูลและความสามารถในการขยายระบบ
- ความท้าทายของ WebHooks
- การจัดการข้อผิดพลาด: หากฝั่งรับ WebHook ล่มหรือมีข้อผิดพลาดในการประมวลผล callback ก็มีความเสี่ยงที่ข้อมูลจะสูญหาย ระบบที่ใช้ WebHook จึงควรมีกลไกจัดการข้อผิดพลาดที่แข็งแรง เช่น การ retry หรือการทำ log
- ประเด็นด้านความปลอดภัย: WebHook ส่งข้อมูลผ่านอินเทอร์เน็ต จึงเสี่ยงต่อการถูกดักจับข้อมูลหรือการโจมตีที่เป็นอันตราย มาตรการความปลอดภัยของ API เช่น การใช้ HTTPS และการเซ็น payload จึงเป็นสิ่งจำเป็น
- การจัดการ WebHook หลายตัว: การจัดการและมอนิเตอร์ WebHook อาจซับซ้อน โดยเฉพาะเมื่อแอปพลิเคชันเติบโตและเริ่มพึ่งพา WebHook หลายตัว ต้องคอยตรวจสอบให้ทุก WebHook ทำงานถูกต้องและติดตาม endpoint ต่างๆ อย่างใกล้ชิด
- ความเป็นไปได้ที่จะเกิด overload: callback จำนวนมากที่เกิดขึ้นพร้อมกันอาจสร้างภาระให้ฝั่งรับของแอปพลิเคชันได้ แต่การจำกัดอัตราและการประมวลผลแบบแบตช์อาจช่วยจัดการกับช่วงที่มีปริมาณพุ่งสูงได้
GraphQL
- GraphQL เป็นทั้ง query language สำหรับ API และ server-side runtime สำหรับรันคำขอโดยใช้ระบบชนิดข้อมูลที่กำหนดไว้กับข้อมูล
- GraphQL ถูกพัฒนาโดย Facebook ในปี 2012 และเปิดตัวเป็นโครงการโอเพนซอร์สในปี 2015 โดยนำเสนอทางเลือกที่ยืดหยุ่นและมีประสิทธิภาพกว่าสำหรับ REST API แบบเดิม
- GraphQL มีอัตราการนำไปใช้เพิ่มขึ้นเป็น 29% ในหมู่นักพัฒนา ซึ่งสะท้อนถึงความสำคัญในภูมิทัศน์ API ปัจจุบัน
- ต่างจาก REST ที่อาจต้องผ่านหลาย API endpoint เพื่อดึงข้อมูลที่เกี่ยวข้อง GraphQL ช่วยให้ได้ข้อมูลทั้งหมดที่ต้องการจาก query เดียว
- สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับนักพัฒนา frontend เพราะทำให้ควบคุมกระบวนการดึงข้อมูลได้มากขึ้น และช่วยสร้างส่วนติดต่อผู้ใช้ที่ dynamic และ responsive มากขึ้น
- ข้อดีของ GraphQL
- สคีมาที่มีการกำหนดชนิดข้อมูลอย่างเข้มงวด: GraphQL API มี schema ที่กำหนดชนิดข้อมูลไว้อย่างชัดเจน ทำให้นักพัฒนารู้ได้แน่นอนว่ามีข้อมูลและชนิดข้อมูลใดให้ใช้ใน query บ้าง
- การดึงข้อมูลได้อย่างแม่นยำ: ไคลเอนต์สามารถขอข้อมูลที่ต้องการได้อย่างตรงจุด ซึ่งช่วยแก้ปัญหา over-fetching และ under-fetching และยังช่วยปรับปรุงประสิทธิภาพและลดต้นทุน
- ความซับซ้อนของ query และทรัพยากรที่หลากหลาย: GraphQL รองรับการ query ข้อมูลหลายประเภทในคำขอเดียว จึงช่วยลดจำนวนคำขอเครือข่ายสำหรับข้อมูลที่ซับซ้อนและเชื่อมโยงกัน
- อัปเดตแบบเรียลไทม์ผ่าน subscription: GraphQL รองรับการซิงก์แบบเรียลไทม์ผ่าน subscription ทำให้ไคลเอนต์ได้รับการอัปเดตแบบทันที
- การ introspection: schema ที่อธิบายตัวเองได้ของ GraphQL ช่วยให้พัฒนาได้ง่ายขึ้นผ่านการตรวจสอบตัวเอง
- ความท้าทายของ GraphQL
- ความซับซ้อนของ query: ความยืดหยุ่นที่ GraphQL มอบให้ไคลเอนต์ก็มีข้อเสีย เพราะ query ที่ซับซ้อนหรือซ้อนลึกเกินไปอาจส่งผลลบต่อประสิทธิภาพ
- learning curve: GraphQL มี learning curve ที่ชันกว่า REST เนื่องจากมีแนวคิดใหม่อย่าง mutation และ subscription
- การจัดการเวอร์ชัน: ธรรมชาติที่ยืดหยุ่นของ query หมายความว่าการเปลี่ยน schema อาจทำให้ query เดิมใช้งานไม่ได้ และทำให้การจัดการเวอร์ชันซับซ้อนขึ้น
- ความเป็นไปได้ในการใช้ทรัพยากรมากเกินไป: ไคลเอนต์สามารถขอหลายทรัพยากรใน query เดียว จึงมีความเสี่ยงที่จะดึงข้อมูลมากเกินความจำเป็นและทำให้เซิร์ฟเวอร์รับภาระหนัก
- ประเด็นด้านความปลอดภัย: ผู้ใช้ที่ไม่หวังดีอาจใช้ประโยชน์จากความยืดหยุ่นของ GraphQL เพื่อทำให้เซิร์ฟเวอร์ overload ด้วย query ที่ซับซ้อน
SOAP
- SOAP(Simple Object Access Protocol) เป็นโปรโตคอลสำหรับแลกเปลี่ยนข้อมูลที่มีโครงสร้างเพื่อใช้งานเว็บเซอร์วิส
- ใช้ XML เป็นรูปแบบข้อความ และโดยทั่วไปใช้ HTTP หรือ SMTP เป็นชั้นสำหรับการเจรจาข้อความและการส่งข้อมูล
- ต่างจาก REST และ GraphQL, SOAP มีมาตรฐานที่เข้มงวดและความสามารถในตัว เช่น ธุรกรรมที่รองรับ ACID ความปลอดภัย และรูปแบบการรับส่งข้อความ
- แม้การใช้งานจะลดลงเหลือเพียง 26% ของนักพัฒนา แต่ SOAP ก็ยังเป็นตัวเลือกที่เชื่อถือได้สำหรับบางแอปพลิเคชัน
- ข้อดีของ SOAP
- การกำหนดชนิดข้อมูลที่เข้มงวดและสัญญาที่ชัดเจน: มีการกำหนดชนิดข้อมูลอย่างเข้มงวดและมีสัญญาที่เคร่งครัดตามที่นิยามไว้ในเอกสาร WDSL(Web Services Description Language)
- ความสามารถด้านความปลอดภัยในตัว: SOAP มอบความปลอดภัยที่ครอบคลุมผ่านการยืนยันตัวตน การกำหนดสิทธิ์ และการเข้ารหัสที่นำมาใช้ผ่านมาตรฐาน WS-Security จึงเป็นตัวเลือกที่นิยมสำหรับแอปพลิเคชันระดับองค์กร
- ธุรกรรมแบบ ACID: SOAP รองรับธุรกรรมแบบ ACID ซึ่งจำเป็นอย่างยิ่งสำหรับแอปพลิเคชันที่ความถูกต้องสมบูรณ์ของข้อมูลมีความสำคัญ เช่น ระบบการเงินหรือสาธารณสุข
- การส่งข้อความที่เชื่อถือได้: SOAP ช่วยรับประกันการส่งข้อความที่เชื่อถือได้และจัดการข้อผิดพลาดได้ดี จึงเหมาะมากกับระบบที่การรับประกันการส่งข้อความเป็นเรื่องสำคัญ
- เป็นกลางต่อภาษา แพลตฟอร์ม และการขนส่งข้อมูล: เช่นเดียวกับ REST บริการ SOAP สามารถใช้งานได้จากไคลเอนต์ใดก็ได้ที่เข้าใจ XML โดยไม่ขึ้นกับภาษาโปรแกรม แพลตฟอร์ม หรือโปรโตคอลขนส่งข้อมูลพื้นฐาน
- ความท้าทายของ SOAP
- ความซับซ้อนและ learning curve: SOAP อาจนำไปใช้ได้ซับซ้อนกว่าเนื่องจากมาตรฐานที่เข้มงวดและการใช้ XML ทำให้มี learning curve ที่ชันกว่าทางเลือกอย่าง REST หรือ GraphQL
- ข้อความที่มีรายละเอียดมาก: header ของข้อความ SOAP มี overhead สูง ทำให้ payload ใหญ่กว่า JSON ของ REST และ GraphQL ซึ่งอาจกระทบต่อประสิทธิภาพและการใช้แบนด์วิดท์
- การสนับสนุนจากชุมชนที่จำกัด: SOAP กำลังสูญเสียความนิยม ซึ่งหมายถึงการสนับสนุนจากชุมชนและไลบรารีที่ใช้งานได้มีแนวโน้มลดลง
- มีความยืดหยุ่นน้อยกว่า: เมื่อสัญญามีการเปลี่ยนแปลง ทั้งไคลเอนต์และเซิร์ฟเวอร์อาจต้องอัปเดตการใช้งานของตน ซึ่งอาจเป็นข้อเสีย
- ปัญหาไฟร์วอลล์: SOAP อาจใช้โปรโตคอลขนส่งข้อมูลที่ต่างจาก HTTP/HTTPS ซึ่งอาจเจอกับข้อจำกัดของไฟร์วอลล์ ส่งผลให้ SOAP มีความอเนกประสงค์ลดลงในบางสภาพแวดล้อมการปรับใช้
WebSocket
- WebSocket ให้การเชื่อมต่อแบบสองทางระหว่างไคลเอนต์และเซิร์ฟเวอร์ที่คงอยู่ต่อเนื่องและมี latency ต่ำ ทำให้สามารถส่งข้อมูลแบบเรียลไทม์ได้
- ต่างจากวงจร request-response ของ HTTP, WebSocket ช่วยให้เซิร์ฟเวอร์สามารถส่งข้อมูลไปยังไคลเอนต์ได้ทุกเมื่อหลังจากการจับมือเริ่มต้น
- ช่วยให้การอัปเดตข้อมูลทันทีทำได้ง่ายสำหรับแอปแชต เกมออนไลน์ แพลตฟอร์มซื้อขาย และอื่นๆ
- จากผลสำรวจพบว่านักพัฒนา 25% ใช้งาน WebSocket
- ข้อดีของ WebSocket
- การสื่อสารสองทางแบบเรียลไทม์: การสื่อสารสองทางแบบเรียลไทม์มี latency ต่ำกว่าการเชื่อมต่อ HTTP ที่ต้องตั้งใหม่ทุกครั้งที่มีการแลกเปลี่ยนข้อมูล
- ลด overhead: หลังการจับมือเริ่มต้น การเชื่อมต่อจะยังคงเปิดอยู่ จึงลด overhead ของ header ที่มากับคำขอ HTTP แบบเดิม
- ใช้ทรัพยากรได้อย่างมีประสิทธิภาพ: การเชื่อมต่อถาวรใช้ทรัพยากรเซิร์ฟเวอร์ได้มีประสิทธิภาพกว่าการทำ long polling
- ความท้าทายของ WebSocket
- ความซับซ้อนในการนำไปใช้: การนำ WebSocket ไปใช้จริงอาจซับซ้อนและใช้เวลามากกว่าสถาปัตยกรรม API แบบอื่น โดยเฉพาะเมื่อต้องคำนึงถึงความจำเป็นของทางเลือกสำรองในสภาพแวดล้อมที่ไม่รองรับ WebSocket
- ขาดความสามารถในตัว: ต่างจาก SOAP ที่มีฟังก์ชันด้านความปลอดภัยและธุรกรรมในตัว WebSocket มีลักษณะใกล้เคียงระดับพื้นฐานมากกว่า ทำให้นักพัฒนาต้องสร้างความสามารถเหล่านี้เอง
- การใช้ทรัพยากร: แม้การเชื่อมต่อ WebSocket แบบเปิดจะมีประสิทธิภาพกว่าการทำ long polling โดยทั่วไป แต่ก็ยังใช้ทรัพยากรของเซิร์ฟเวอร์และอาจเป็นปัญหาได้เมื่อขยายขนาดมากๆ
- ข้อจำกัดของเครือข่าย: proxy และไฟร์วอลล์บางตัวไม่รองรับ WebSocket จึงอาจเกิดปัญหาการเชื่อมต่อในสภาพแวดล้อมเครือข่ายบางประเภท
gRPC
- gRPC ซึ่งย่อมาจาก "Google Remote Procedure Call" เป็นโปรโตคอลสมัยใหม่ประสิทธิภาพสูงที่ช่วยให้การสื่อสารระหว่างบริการทำได้สะดวก
- สร้างขึ้นบน HTTP/2 และใช้ protocol buffers เพื่อกำหนดวิธีการของบริการและรูปแบบข้อความ
- ต่างจาก REST API ที่ใช้ HTTP verbs มาตรฐานอย่าง GET และ POST, gRPC รองรับการเปิดเผยเมธอดแบบกำหนดเองในบริการซึ่งคล้ายกับฟังก์ชันของภาษาโปรแกรม
- ข้อดีของ gRPC
- ประสิทธิภาพ: การใช้ HTTP/2 และ protocol buffers ช่วยให้ gRPC มี latency ต่ำและ throughput สูง
- การกำหนดชนิดข้อมูลอย่างเข้มงวด: เช่นเดียวกับ SOAP และ GraphQL, gRPC มีการกำหนดชนิดข้อมูลอย่างเข้มงวด ส่งผลให้สามารถตรวจสอบชนิดข้อมูลได้ตั้งแต่คอมไพล์ไทม์และช่วยลดบั๊ก
- รองรับหลายภาษา: gRPC รองรับภาษาโปรแกรมหลากหลายได้อย่างยอดเยี่ยม รวมถึง Go, Java, C# และ Node.js
- สตรีมมิง: gRPC รองรับการจัดการคำขอและการตอบกลับแบบสตรีมมิงได้ทันที จึงนำไปใช้กับกรณีใช้งานที่ซับซ้อน เช่น การเชื่อมต่อระยะยาวและการอัปเดตแบบเรียลไทม์ได้
- มาพร้อมความสามารถสำคัญในตัว: gRPC รองรับความสามารถสำคัญโดยตรง เช่น load balancing, retry และ timeout
- ความท้าทายของ gRPC
- การรองรับในเบราว์เซอร์: การรองรับ gRPC แบบ native ในเบราว์เซอร์ยังมีข้อจำกัดอยู่มาก จึงไม่เหมาะกับการสื่อสารโดยตรงระหว่างไคลเอนต์กับเซิร์ฟเวอร์ในเว็บแอปพลิเคชัน
- learning curve: นักพัฒนาต้องเรียนรู้วิธีใช้ protocol buffers การนิยามบริการแบบกำหนดเอง และความสามารถอื่นๆ ของ gRPC ซึ่งอาจลดประสิทธิภาพการทำงานช่วงเริ่มต้น
- ความซับซ้อนในการดีบัก: protocol buffers ไม่สามารถอ่านได้ง่ายโดยมนุษย์ จึงทำให้การดีบักและทดสอบ gRPC API ยากกว่า JSON API
โปรโตคอล API อื่นๆ
- MQTT : โปรโตคอลส่งข้อความน้ำหนักเบาที่เหมาะกับเครือข่ายแบนด์วิดท์ต่ำ เช่น IoT ไคลเอนต์สามารถ publish และ subscribe ข้อความผ่าน broker ได้ แต่ขาดความสามารถบางด้านในเรื่องความปลอดภัยและการขยายระบบ
- AMQP : มาตรฐาน enterprise messaging ที่แข็งแกร่งกว่า ซึ่งช่วยรับประกันการส่งข้อความที่เชื่อถือได้และการกำหนดเส้นทางข้อความที่ยืดหยุ่น อย่างไรก็ตามอาจซับซ้อนกว่าและมี overhead มากกว่าโปรโตคอลแบบ lightweight
- SSE : ช่วยให้มีการสื่อสารทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์ผ่าน HTTP เหมาะกับการอัปเดตแบบเรียลไทม์ แต่ขาดความสามารถแบบสองทาง
- EDI : ทำให้การสื่อสารแบบ B2B เป็นอัตโนมัติด้วยการทำเอกสารอิเล็กทรอนิกส์ เช่น ใบสั่งซื้อและใบแจ้งหนี้ ให้เป็นมาตรฐาน แต่มีต้นทุนเริ่มต้นสูงและต้องใช้โครงสร้างพื้นฐานที่ซับซ้อน
- EDA : ส่งเสริมสถาปัตยกรรมแบบ event-driven ที่องค์ประกอบต่างๆ ตอบสนองต่อเหตุการณ์ ทำให้สร้างระบบเรียลไทม์ที่ขยายได้ แต่การดีบักมีความซับซ้อน
บทสรุป
- ภูมิทัศน์ของ API ยังคงพัฒนาอย่างต่อเนื่อง ขณะที่นักพัฒนานำสถาปัตยกรรม โปรโตคอล และเครื่องมือใหม่ๆ มาใช้
- แม้ REST จะยังคงครองความนิยมด้วยความเรียบง่ายและการมีอยู่ทั่วไป แต่ทางเลือกอย่าง GraphQL และ gRPC ก็กำลังได้รับความสนใจจากการช่วยแก้จุดเจ็บปวด เช่น over-fetching และอินเทอร์เฟซที่ต้องคุยหลายรอบ
- นอกจากนี้ นักพัฒนายังให้ความสำคัญกับ WebHooks และ WebSocket มากขึ้นเรื่อยๆ เพราะความต้องการด้านการสื่อสารแบบเรียลไทม์
- สำหรับกรณีการใช้งาน API ทั่วไปจำนวนมาก REST ยังคงเป็นแนวทางพื้นฐานที่มั่นคง เมื่อพิจารณาจากความสามารถในการขยายระบบ การทำงานร่วมกันได้ และความง่ายในการนำไปใช้ อีกทั้งยังได้เปรียบจากความเติบโตเต็มที่ของชุมชน
- ถึงกระนั้น ทุกโปรโตคอลต่างก็มีข้อดีและข้อเสียของตัวเอง และเมื่อแอปพลิเคชันมีความซับซ้อนมากขึ้น นักพัฒนาก็กำลังขยายชุดเครื่องมือด้านโปรโตคอล API อย่างชาญฉลาดให้ครอบคลุมโซลูชันเฉพาะทางอย่าง GraphQL และ gRPC
- มากกว่าการมองหายาวิเศษแบบใช้ได้กับทุกกรณี นักพัฒนา API ควร เข้าใจจุดแข็งและจุดอ่อนของหลายโปรโตคอล
- ด้วยการออกแบบระบบที่ผสาน REST, WebHook, WebSocket, GraphQL และแนวทางอื่นๆ ที่แต่ละแบบมีจุดเด่นเฉพาะตัว นักพัฒนาจะสามารถสร้าง API ที่แข็งแรง มีประสิทธิภาพ และดูแลรักษาได้
- แม้ความนิยมของแต่ละโปรโตคอลจะยังคงผันผวนต่อไป แต่แนวโน้มที่สำคัญที่สุดคือ ความหลากหลายที่เพิ่มขึ้น ในภูมิทัศน์ของ API
- นักพัฒนาควรยอมรับ แนวคิดแบบหลายโปรโตคอล นี้เพื่อสร้างโซลูชัน API ที่เหมาะสมที่สุด
3 ความคิดเห็น
อ่านได้ดีเลยค่า
ถ้าไม่ใช่งานที่เป็นการกระทำครั้งเดียวแบบจบในรอบเดียว แต่เป็นงานที่ต้องดำเนินต่อเนื่อง ทรานแซกชันก็น่าจะเป็นสิ่งจำเป็นไม่ใช่เหรอครับ? (ผมก็เห็นด้วยนะครับกับความย้อนแย้งที่บอกว่าจำเป็น แต่เพิ่งจะมุ่งไปทาง REST เอาตอนนี้ 555)