API หรือ Application Programming Interface นำเสนอฟังก์ชันและกฎที่อนุญาตการโต้ตอบและการสื่อสารระหว่างแอปพลิเคชันต่างๆ อินเทอร์เฟซเหล่านี้อำนวยความสะดวกในการรวมแอปพลิเคชัน ทำให้นักพัฒนาสามารถสร้างผลิตภัณฑ์ดิจิทัลที่ทรงพลังได้
API เป็นสื่อกลางระหว่างแอปพลิเคชันผ่านคำขอและการตอบกลับ ตัวอย่างเช่น การลงทะเบียนในแอปพลิเคชันผ่านบัญชี Twitter ที่มีอยู่ของผู้ใช้เกิดขึ้นผ่าน Twitter API ที่นักพัฒนาซอฟต์แวร์ได้รวมเข้ากับแอป
API ใช้โปรโตคอลและสถาปัตยกรรมที่หลากหลายสำหรับการส่งคำขอและการตอบกลับ:
- XML-RPC — ช่วยให้สามารถแลกเปลี่ยนฟังก์ชันระหว่างเครือข่ายได้ XML-RPC ใช้ XML เพื่ออธิบายการตอบสนอง/คำขอและโปรโตคอล HTTP สำหรับการถ่ายโอนข้อมูลจากไคลเอนต์ไปยังเซิร์ฟเวอร์
- JSON-RPC เป็น RPC น้ำหนักเบาที่คล้ายกับ XML ที่นี่โปรโตคอลถูกเข้ารหัสใน JSON; อนุญาตให้รับสายไปยังเซิร์ฟเวอร์ด้วยการตอบสนองแบบอะซิงโครนัส
- SOAP — โปรโตคอลการเข้าถึงวัตถุอย่างง่ายสำหรับการแลกเปลี่ยนข้อมูลที่มีโครงสร้างเมื่อใช้บริการเว็บในเครือข่ายคอมพิวเตอร์ SOAP ใช้ XML สำหรับการพิสูจน์ตัวตน การอนุญาต และการสื่อสารกระบวนการบนระบบปฏิบัติการ ช่วยให้ลูกค้าสามารถเรียกบริการเว็บและรับการตอบสนองโดยไม่คำนึงถึงแพลตฟอร์มและภาษา
- REST API (การถ่ายโอนสถานะตัวแทน) — รูปแบบสถาปัตยกรรมที่ใช้การใช้งานไคลเอ็นต์-เซิร์ฟเวอร์อย่างอิสระ REST ใช้โปรโตคอล HTTP สำหรับการสื่อสาร
ในโพสต์นี้ เราเน้นที่ REST API กำหนด และวิเคราะห์ว่าแตกต่างจาก API อื่นๆ อย่างไร
การกำหนด REST API
REST เป็นรูปแบบสถาปัตยกรรมสำหรับการออกแบบ API ผ่านโปรโตคอล HTTP ประโยชน์หลักของมันคือความยืดหยุ่นที่ยอดเยี่ยม
นักพัฒนาใช้ REST API ทุกที่ที่มีความจำเป็นต้องให้ข้อมูลแก่ผู้ใช้เว็บแอปพลิเคชันหรือไซต์โดยตรงจากเซิร์ฟเวอร์
ส่วนประกอบหลักของ REST API:
- ลูกค้า — ลูกค้าหรือโปรแกรมที่เปิดตัวทางฝั่งผู้ใช้ (บนอุปกรณ์ของเขา) เพื่อเริ่มต้นการสื่อสาร
- เซิร์ฟเวอร์ — เซิร์ฟเวอร์ที่ใช้ API เพื่อเข้าถึงฟังก์ชันและข้อมูล
- ทรัพยากร — เนื้อหาใด ๆ (วิดีโอ ข้อความ รูปภาพ) ที่เซิร์ฟเวอร์ส่งไปยังไคลเอนต์
REST API ทำงานอย่างไร
REST API สื่อสารผ่านคำขอ HTTP โดยทำหน้าที่ต่อไปนี้ให้สมบูรณ์ — สร้าง อ่าน อัปเดต และลบข้อมูล พวกเขายังเป็นที่รู้จักกันในนามการดำเนินการ CRUD REST ให้ข้อมูลเกี่ยวกับทรัพยากรที่ร้องขอ และใช้สี่วิธีในการอธิบายว่าจะทำอย่างไรกับทรัพยากร:
- POST — การสร้างทรัพยากร
- GET — รับทรัพยากร
- PUT — อัปเดตทรัพยากร
- DELETE — การลบทรัพยากร
ทรัพยากร
ทรัพยากรเป็นแนวคิดที่สำคัญใน REST API ซึ่งเป็นนามธรรมของข้อมูล อาจเป็นข้อมูลใด ๆ ก็ได้ เอกสาร รูปภาพ บริการชั่วคราว
สถานะของทรัพยากร ณ เวลาใดก็ตามเรียกว่าการแสดงแทนทรัพยากร ซึ่งประกอบด้วยข้อมูล เมตาดาต้าที่อธิบายข้อมูล และลิงก์ไฮเปอร์มีเดียเพื่อช่วยให้ลูกค้าย้ายไปยังสถานะถัดไป
ข้อมูลสามารถส่งไปยังไคลเอนต์ในรูปแบบต่างๆ: JSON, HTML, XLT, Python หรือข้อความธรรมดา ที่นิยมและใช้กันมากที่สุดคือ JSON เนื่องจากเป็นแบบที่มนุษย์สามารถอ่านได้ด้วยเครื่องและไม่เชื่อเรื่องภาษา
ในการเข้าถึงทรัพยากร ลูกค้าจำเป็นต้องส่งคำขอ หลังจากได้รับแล้ว เซิร์ฟเวอร์จะสร้างการตอบสนองด้วยข้อมูลที่เข้ารหัสเกี่ยวกับทรัพยากร
โครงสร้างคำขอประกอบด้วยสี่องค์ประกอบหลัก: วิธี HTTP (CRUD ที่เรากล่าวถึงก่อนหน้านี้) จุดปลาย ส่วนหัว และเนื้อหา
เมธอด HTTP อธิบายสิ่งที่ควรทำกับรีซอร์ส ข้างต้น เราได้กล่าวถึงสี่วิธีที่ใช้ได้: POST, GET, PUT, DELETE
จุดสิ้นสุด มี URI — Uniform Resource Identifier ซึ่งระบุว่าจะพบทรัพยากรได้อย่างไรและที่ไหน URL หรือ Uniform Resource Location เป็นประเภท URI ที่พบบ่อยที่สุด ซึ่งแสดงถึงที่อยู่เว็บแบบเต็ม
ส่วนหัว มีข้อมูลที่เกี่ยวข้องกับไคลเอนต์และเซิร์ฟเวอร์ ส่วนหัวรวมถึงข้อมูลการตรวจสอบสิทธิ์: คีย์ API ชื่อ ที่อยู่ IP ที่เป็นของคอมพิวเตอร์ที่ติดตั้งเซิร์ฟเวอร์ และข้อมูลเกี่ยวกับรูปแบบการตอบสนอง
เนื้อหา ใช้เพื่อส่งข้อมูลเพิ่มเติมไปยังเซิร์ฟเวอร์ เช่น ข้อมูลที่คุณต้องการเพิ่ม
หลักการ REST API
REST ไม่ได้ผูกติดอยู่กับเทคโนโลยีหรือแพลตฟอร์มใดโดยเฉพาะ มันไม่ขึ้นกับภาษา นอกจากนี้ยังไม่ได้ระบุวิธีการสร้าง API อย่างแม่นยำอีกด้วย แต่ใช้ข้อจำกัดทางสถาปัตยกรรม 6 ประการ อินเทอร์เฟซสามารถเรียกได้ว่าเป็น REST API ที่ถูกต้องโดยปฏิบัติตามข้อจำกัดเหล่านั้น พวกเขาอธิบายวิธีที่เซิร์ฟเวอร์ประมวลผลคำขอและตอบสนองต่อคำขอเหล่านั้น
ไคลเอนต์-เซิร์ฟเวอร์
REST API ใช้รูปแบบสถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์ ลูกค้าส่งคำขอทรัพยากรและไม่เกี่ยวข้องกับการจัดเก็บข้อมูล การจัดเก็บข้อมูลยังคงอยู่ภายในเซิร์ฟเวอร์ เซิร์ฟเวอร์ไม่มีส่วนเกี่ยวข้องในการสื่อสารกับส่วนต่อประสานผู้ใช้ ไคลเอนต์และเซิร์ฟเวอร์มีวิวัฒนาการอย่างอิสระ ปัจจัยนี้ทำให้ REST มีความยืดหยุ่นและปรับขนาดได้มากขึ้น
อินเทอร์เฟซที่สม่ำเสมอ
อินเทอร์เฟซแบบรวมเป็นปัจจัยสำคัญที่ทำให้ REST API แตกต่าง มันระบุว่ามีวิธีเดียวในการสื่อสารกับเซิร์ฟเวอร์ ไม่ได้หมายความถึงประเภทของแอปพลิเคชันและอุปกรณ์
อินเทอร์เฟซที่เหมือนกันมีสี่หลักการ:
- การระบุทรัพยากร ทรัพยากรแต่ละรายการต้องมีการระบุที่ไม่ขึ้นอยู่กับสถานะของทรัพยากร URL ทำหน้าที่เป็นตัวระบุ
- การจัดการทรัพยากรผ่านการเป็นตัวแทน การแสดงทรัพยากร (ที่ลูกค้ามี) มีข้อมูลที่จำเป็นในการลบหรือแก้ไขทรัพยากร ไคลเอ็นต์ส่งการแทนว่าเซิร์ฟเวอร์ (อ็อบเจ็กต์ JSON) จำเป็นต้องแก้ไข ลบ หรือเพิ่ม
- ข้อความอธิบายตนเอง ข้อความดังกล่าวมีข้อมูลทั้งหมดสำหรับผู้รับเพื่อความเข้าใจ ไม่ต้องการข้อมูลเพิ่มเติมในเอกสารหรือข้อความแยกต่างหาก แต่ละข้อความมีข้อมูลเพียงพอสำหรับเซิร์ฟเวอร์ในการแยกวิเคราะห์คำขอ
- Hypermedia เป็นเครื่องมือของสถานะแอปพลิเคชัน Hypermedia ต้องการการใช้ลิงก์สำหรับการตอบสนองแต่ละครั้ง เพื่อให้ไคลเอ็นต์สามารถค้นหาทรัพยากรอื่นๆ ได้ ใน REST ไฮเปอร์มีเดียถูกใช้สำหรับการโต้ตอบทั้งหมด
ไร้สัญชาติ
หมายความว่าเซิร์ฟเวอร์ไม่มีข้อมูลใด ๆ เกี่ยวกับไคลเอนต์ ข้อมูลทั้งหมดที่จำเป็นสำหรับการประมวลผลคำขอจะรวมอยู่ในคำขอ ลูกค้าเก็บข้อมูลเซสชันทั้งหมด
แคชได้
การตอบสนองแต่ละครั้งต้องมีข้อมูลที่แจ้งว่าสามารถแคชได้หรือไม่ และระยะเวลาที่สามารถแคชการตอบกลับได้ หากแคชได้ ในคำขอที่คล้ายกัน ไคลเอ็นต์สามารถใช้ข้อมูลเดียวกันได้โดยไม่ต้องส่งคำขอซ้ำๆ ไปยังเซิร์ฟเวอร์ ช่วยปรับปรุงประสิทธิภาพและความพร้อมใช้งาน
ระบบชั้น
REST ใช้ลำดับชั้นของเลเยอร์ ซึ่งสร้างข้อจำกัดบางประการเกี่ยวกับการทำงานของส่วนประกอบ ในระบบแบบเลเยอร์ ส่วนประกอบสามารถดูได้เฉพาะส่วนประกอบที่อยู่ในระดับที่ใกล้ที่สุดและระดับที่โต้ตอบด้วย
รหัสตามความต้องการ
เป็นคุณสมบัติเสริมที่ช่วยให้ลูกค้าสามารถดาวน์โหลดและรันโค้ดได้
REST API แตกต่างอย่างไร
หลักการทั้ง 6 ประการของ REST API ถือได้ว่าเป็นข้อแตกต่างที่สำคัญระหว่างอินเทอร์เฟซนี้กับประเภทอื่นๆ นอกจากนี้ พารามิเตอร์หลายตัวยังแยกแยะ REST
ประการแรก แก่นแท้ของ REST เป็นตัวกำหนดความไม่ลงรอยกันกับประเภทอื่นๆ เป็นรูปแบบสถาปัตยกรรมที่สถาปัตยกรรมแสดงถึงชุดข้อกำหนดที่คุณต้องปฏิบัติตามเพื่อให้บริการเว็บ RESTful ตัวอย่างเช่น SOAP และ RPC เป็นโปรโตคอลการส่งข้อความที่อธิบายข้อความ ต่างจากรูปแบบสถาปัตยกรรมซึ่งระบุเฉพาะข้อกำหนด (ข้อจำกัด) ที่ข้อความต้องปฏิบัติตาม
โครงสร้าง
โดยปกติ API จะเป็นไปตามรูปแบบแอปต่อแอป ในขณะที่ REST จะใช้โครงสร้างที่แตกต่างกัน — ไคลเอ็นต์-เซิร์ฟเวอร์ ไคลเอนต์และเซิร์ฟเวอร์มีการพัฒนาอย่างอิสระ ทำให้มีความยืดหยุ่นในการทำงานมากขึ้น
รูปแบบการแลกเปลี่ยนข้อความ
API มักใช้รูปแบบข้อความเฉพาะ ตัวอย่างเช่น SOAP ใช้ XML REST ไม่ปฏิบัติตามหลักการที่เข้มงวดดังกล่าว สามารถใช้รูปแบบใดก็ได้ในการแลกเปลี่ยนข้อมูล อย่างไรก็ตาม JSON เป็นที่นิยมมากที่สุดในขณะนี้
มีเหตุผลที่ชัดเจนเบื้องหลังความนิยมของ JSON — เป็นแบบที่มนุษย์อ่านได้และวิเคราะห์รูปแบบการแลกเปลี่ยนข้อมูลได้ง่าย JSON ไม่ขึ้นกับภาษา และคุณสามารถใช้กับภาษาใดก็ได้นอกเหนือจาก JavaScript
ความยืดหยุ่น
REST เป็นรูปแบบสถาปัตยกรรมที่ยืดหยุ่น นักพัฒนาจึงใช้กันอย่างแพร่หลาย เมื่อเทียบกับ SOAP — โปรโตคอลที่ซับซ้อนมากขึ้นพร้อมคุณสมบัติการรักษาความปลอดภัยขั้นสูงที่ต้องการแบนด์วิดธ์มากกว่า REST ประกอบด้วยแนวทางง่ายๆ ที่อนุญาตให้นักพัฒนาใช้ข้อกำหนดเหล่านั้นในรูปแบบของพวกเขา สถาปัตยกรรมให้ประสิทธิภาพสูง ทำให้มีความต้องการอุปกรณ์มือถือโดยเฉพาะ ซึ่งความเร็วในการดาวน์โหลดเป็นสิ่งสำคัญ
ดังที่เราเห็น REST มีข้อได้เปรียบเหนือ API อื่นๆ ที่รู้จัก นั่นคือเหตุผลที่บริษัทชั้นนำทั้งหมด เช่น Twitter และ Google ได้ปรับใช้มันสำหรับผลิตภัณฑ์ของตน เพราะเป็นวิธีที่เหมาะและง่ายในการถ่ายโอนข้อมูลไปยังนักพัฒนาทั่วโลก และเป็นกลไกที่ได้รับการพิสูจน์แล้วสำหรับการสร้างอินเทอร์เฟซที่มีประสิทธิภาพและปรับขนาดได้สำหรับการพัฒนาซอฟต์แวร์