REST API คืออะไรและแตกต่างจากประเภทอื่นอย่างไร

API หรือ Application Programming Interface นำเสนอฟังก์ชันและกฎที่อนุญาตการโต้ตอบและการสื่อสารระหว่างแอปพลิเคชันต่างๆ อินเทอร์เฟซเหล่านี้อำนวยความสะดวกในการรวมแอปพลิเคชัน ทำให้นักพัฒนาสามารถสร้างผลิตภัณฑ์ดิจิทัลที่ทรงพลังได้

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

API ใช้โปรโตคอลและสถาปัตยกรรมที่หลากหลายสำหรับการส่งคำขอและการตอบกลับ:

1. XML-RPC — ช่วยให้สามารถแลกเปลี่ยนฟังก์ชันระหว่างเครือข่ายได้ XML-RPC ใช้ XML เพื่ออธิบายการตอบสนอง/คำขอและโปรโตคอล HTTP สำหรับการถ่ายโอนข้อมูลจากไคลเอนต์ไปยังเซิร์ฟเวอร์
2. JSON-RPC เป็น RPC น้ำหนักเบาที่คล้ายกับ XML ที่นี่โปรโตคอลถูกเข้ารหัสใน JSON; อนุญาตให้รับสายไปยังเซิร์ฟเวอร์ด้วยการตอบสนองแบบอะซิงโครนัส
3. SOAP — โปรโตคอลการเข้าถึงวัตถุอย่างง่ายสำหรับการแลกเปลี่ยนข้อมูลที่มีโครงสร้างเมื่อใช้บริการเว็บในเครือข่ายคอมพิวเตอร์ SOAP ใช้ XML สำหรับการพิสูจน์ตัวตน การอนุญาต และการสื่อสารกระบวนการบนระบบปฏิบัติการ ช่วยให้ลูกค้าสามารถเรียกบริการเว็บและรับการตอบสนองโดยไม่คำนึงถึงแพลตฟอร์มและภาษา
4. 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 ได้ปรับใช้มันสำหรับผลิตภัณฑ์ของตน เพราะเป็นวิธีที่เหมาะและง่ายในการถ่ายโอนข้อมูลไปยังนักพัฒนาทั่วโลก และเป็นกลไกที่ได้รับการพิสูจน์แล้วสำหรับการสร้างอินเทอร์เฟซที่มีประสิทธิภาพและปรับขนาดได้สำหรับการพัฒนาซอฟต์แวร์