การแลกเปลี่ยนข้อมูลในหลายๆ แพลตฟอร์มมีความสำคัญมากกว่าที่เคยในยุคแห่งการผสานรวม พิจารณา ร้านค้าออนไลน์ ที่ไม่มีการผสานการทำงาน เว็บไซต์ของคุณจะต้องพัฒนาระบบสำหรับการจัดการบัญชีผู้ใช้ การสมัครอีเมล การประมวลผลการชำระเงิน การ จัดส่ง และงานอื่นๆ นอกเหนือจากการจัดการรายการผลิตภัณฑ์ การว่าจ้างผู้ให้บริการรายอื่นจากภายนอกจะมีประสิทธิภาพมากกว่าเนื่องจากนี่ไม่ใช่ตัวเลือกที่ปรับขนาดได้
อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน หรือเว็บ API คือสิ่งที่โปรแกรมซอฟต์แวร์ใช้เพื่อสื่อสารระหว่างกัน API มีโปรโตคอลที่สอดคล้องกันสำหรับการแลกเปลี่ยนข้อมูลระหว่างสองโปรแกรม ด้วยความช่วยเหลือของ API เว็บ ร้านค้าออนไลน์ของคุณสามารถสื่อสารกับซอฟต์แวร์การจัดส่ง แอปพลิเคชันไคลเอ็นต์ แอปพลิเคชันการชำระเงิน และการเชื่อมต่ออื่นๆ ที่จำเป็น
มีหลายวิธีในการสร้าง API; อย่างไรก็ตาม หากคุณต้องการเพิ่มการเชื่อมต่อซอฟต์แวร์ให้กับบริการของคุณ มีเทคนิคเฉพาะอย่างหนึ่งที่คุณควรคุ้นเคย: บริการเว็บ REST API ในบทความนี้ เราจะพูดถึงตัวอย่าง REST API, REST API คืออะไร, REST API ทำงานอย่างไร, ใช้ REST API อะไร, ประวัติ, องค์ประกอบ และอื่นๆ
REST API คืออะไรกันแน่?
การถ่ายโอนสถานะตัวแทนหรือเว็บเซอร์วิส REST API เป็นวิธีปฏิบัติที่เป็นมาตรฐานที่สุดสำหรับการเชื่อมโยงคอมโพเนนต์ในเฟรมเวิร์กไมโครเซอร์วิส เนื่องจากนำเสนอวิธีที่หลากหลายและพกพาได้ในการรวมแอพ REST คือการออกแบบ API ยอดนิยมที่เราใช้เพื่อโต้ตอบกับผู้มีส่วนได้ส่วนเสียภายในและภายนอกในลักษณะที่เป็นมาตรฐานและคาดการณ์ได้
ผู้ใช้เว็บแอปพลิเคชันมักจะใช้บริการเว็บ REST API เพื่อสื่อสารระหว่างกัน ตัวอย่างเช่น การรับและตรวจสอบรายละเอียดบัญชีในโปรแกรม โซเชียลมีเดีย เบราว์เซอร์ REST API สามารถดูเป็นไวยากรณ์ของเว็บได้ ลูกค้าออนไลน์ใช้ API ของเว็บเพื่อให้และจัดการการเข้าถึงการดำเนินการทางดิจิทัลเมื่อการใช้งานคลาวด์เพิ่มขึ้น
การออกแบบเว็บ API ที่ช่วยให้ลูกค้าเชื่อมต่อ จัดการ และมีส่วนร่วมกับบริการเว็บดิจิทัลแบบไดนามิกในบริบทที่กระจัดกระจายเป็นการตัดสินใจที่สมเหตุสมผล เว็บไซต์เช่น Google, eBay, Facebook, Amazon และ Twitter ใช้บริการเว็บ RESTful แอปพลิเคชันไคลเอนต์สามารถใช้ REST เพื่อเข้าถึงบริการเว็บเหล่านี้ได้แล้ว
เทคโนโลยี REST เป็นที่นิยมมากกว่าเทคโนโลยีที่เกี่ยวข้องอื่นๆ นี่เป็นเพราะบริการเว็บ REST ใช้แบนด์วิธน้อยกว่า ซึ่งทำให้เหมาะสำหรับกิจกรรมออนไลน์ที่มีประสิทธิภาพ นอกจากนี้ยังสามารถพัฒนาบริการเว็บ RESTful โดยใช้ภาษาโปรแกรมเช่น JavaScript หรือ Python
REST API ทำงานอย่างไร
หากต้องการทราบว่า REST API ทำงานอย่างไร เราต้องกำหนดคำสำคัญบางคำ:
ลูกค้า
ผู้ใช้ API เรียกว่าไคลเอนต์ ลูกค้าส่งแบบสอบถามไปยัง API ของเว็บเพื่อรับข้อมูลหรือใช้การแก้ไขกับโปรแกรม อินเทอร์เน็ตเบราว์เซอร์ของคุณเป็นไคลเอนต์ มันสื่อสารกับ API ของเว็บต่างๆ เพื่อรับเนื้อหาของเพจ คอมพิวเตอร์ของคุณได้รับข้อมูลที่จำเป็น ซึ่งจะแสดงบนจอแสดงผล
ต่อไปนี้เป็นวิธี HTTP ยอดนิยม:
- ใช้คำขอ GET เพื่อส่งคืนข้อมูลที่ร้องขอหรือทรัพยากรที่ร้องขอ
- ใช้คำขอ POST เพื่อสร้างทรัพยากรใหม่
- ใช้คำสั่ง PUT เพื่อเปลี่ยนแปลงหรืออัปเดตทรัพยากรที่มีอยู่ต่อไป
- ใช้คำสั่ง DELETE เพื่อกำจัดทรัพยากร
ตัวอย่างเช่น คำขอ HTTP ที่ส่งไปยัง API ของ YouTube อาจเป็นทรัพยากรคำขอ GET สำหรับวิดีโอหรือโพสต์หนึ่งๆ หรือคำขอ POST เพื่อเผยแพร่รูปภาพใหม่ คุณสามารถใช้วิธีการร้องขอ POST เพื่อเผยแพร่โพสต์ใหม่ ในทำนองเดียวกัน แพลตฟอร์มบริการเว็บของลูกค้าที่รวมเข้ากับการใช้งานการเข้าร่วมอัตโนมัติอาจใช้คำสั่ง PUT เพื่ออัปเดตหรือกำจัดสวัสดีแบบกำหนดเอง
รับคำขอ
- สามารถแคชคำขอ GET ได้ ประวัติของเบราว์เซอร์รวมถึงคำขอ GET
- สามารถคั่นหน้าคำขอ GET ได้
- อย่าใช้คำขอ GET ในขณะที่ทำงานกับเนื้อหาที่สำคัญ
- คำขอ GET มีความยาวจำกัด
- ทำการสืบค้นข้อมูลผ่านคำขอ GET เท่านั้น
วิธีการโพสต์
คำขอ POST เป็นวิธีการโพสต์สำหรับการส่งข้อมูลไปยังเซิร์ฟเวอร์เพื่อเพิ่มหรืออัปเดตทรัพยากร เนื้อหาคำขอของคำขอ HTTP ประกอบด้วยข้อมูลที่เผยแพร่ไปยังฝั่งเซิร์ฟเวอร์:
- วิธีการโพสต์คำขอ POST ไม่เคยเข้าไปในแคช
- คำขอ POST ไม่ได้ถูกจัดเก็บไว้ในประวัติของเบราว์เซอร์
- คำขอ POST ไม่สามารถบุ๊กมาร์กได้
ร่างกายตอบสนอง
เนื้อหาการตอบสนองเป็นหนึ่งในองค์ประกอบที่สำคัญของ RESTful API ข้อมูลที่ร้องขอจะรวมอยู่ในเนื้อหาการตอบสนอง เนื้อหาการตอบสนองอาจรวมถึงข้อมูลที่เกี่ยวข้องกับเอาต์พุตและพอร์ตลอจิกเอาต์พุต
ทรัพยากร
ข้อมูลใดๆ ที่ API ของเว็บสามารถให้แก่ผู้ใช้ถือเป็นแหล่งข้อมูล ตัวอย่างเช่น บุคคล เพจ รูปภาพ หรือคำพูดทั้งหมดอาจได้รับการพิจารณาว่าเป็นทรัพยากรใน API ของ Facebook ตัวระบุทรัพยากรเป็นคำพิเศษที่กำหนดให้กับแต่ละทรัพยากร
เว็บเซิร์ฟเวอร์
โปรแกรมที่ยอมรับเนื้อหาคำขอของลูกค้าใช้เว็บเซิร์ฟเวอร์ ซึ่งเป็นที่ตั้งของทรัพยากรที่ผู้บริโภคร้องขอ เซิร์ฟเวอร์สามารถสื่อสารกับลูกค้าผ่าน API โดยไม่ต้องให้ลูกค้าเข้าถึงข้อมูลที่เก็บไว้ใน ฐานข้อมูล ได้ทันที เมื่อผู้ใช้เข้าถึงบริการเว็บ RESTful เพื่อส่งเนื้อหาคำขอ เซิร์ฟเวอร์จะส่งภาพสถานะของทรัพยากรที่ปรับให้เป็นมาตรฐานไปยังเบราว์เซอร์
สิ่งนี้บ่งชี้ว่าเซิร์ฟเวอร์ไม่ได้ส่งทรัพยากรที่แน่นอนไปยังไคลเอ็นต์ แต่สะท้อนถึงเงื่อนไขของมัน เช่น สถานการณ์ของทรัพยากร ณ เวลาที่ระบุ เพื่อช่วยในการทำความเข้าใจ การตอบกลับจะถูกส่งกลับในรูปแบบที่มีน้ำหนักเบา
JSON (JavaScript Object Notation) ถูกใช้อย่างกว้างขวางเนื่องจากทั้งคนและเครื่องสามารถอ่านได้ และ excels ช่วยในการส่งเสริมการเข้าถึงเว็บ JSON ใช้เป็นหลักในการส่งเนื้อหาคำขอในเว็บแอปพลิเคชันและไคลเอนต์แอปพลิเคชัน เป็นรูปแบบที่เข้ากันได้กับการเข้ารหัสที่หลากหลาย รูปแบบข้อมูล API อื่นที่ไม่ใช่ JSON เกี่ยวข้องกับ XML , YAML, CSV, HTML และข้อความล้วน ผู้ใช้ API สามารถเลือกรูปแบบข้อมูลที่ต้องการได้โดยใช้ประเภทสื่อแบบกำหนดเอง
ประวัติของ REST API
โปรแกรมเมอร์หลายคนต้องทำงานกับ SOAP ก่อน REST เพื่อรวม API การสร้าง การใช้งาน และการดีบัก SOAP นั้นเป็นงานที่ยากอย่างเลื่องลือ โชคดีที่ REST ได้รับการพัฒนาโดยทีมโปรแกรมเมอร์ภายใต้การดูแลของ Roy Fielding ซึ่งเปลี่ยนแปลงสภาพแวดล้อม API ตลอดไป
นี่คือลำดับเหตุการณ์ของการพัฒนา REST APIs เมื่อเวลาผ่านไป:
ก่อนพักผ่อน
โปรแกรมเมอร์เขียนไฟล์ XML ที่มี Remote Procedure Call (RPC) ด้วยตนเองภายในเนื้อหาเพื่อเชื่อมต่อ API ของเว็บโดยใช้ SOAP หลังจากนั้น นักออกแบบจะโพสต์แพ็คเกจ SOAP ไปยังปลายทางที่ระบุ
ในปี 2543
ทีมโปรแกรมเมอร์ที่นำโดย Roy Fielding เลือกที่จะพัฒนาเฟรมเวิร์กที่ช่วยให้เซิร์ฟเวอร์ทุกเครื่องสามารถสื่อสารกับเซิร์ฟเวอร์อื่นได้ เขาวางข้อจำกัดสำหรับ REST API เนื่องจากหลักเกณฑ์เหล่านี้เป็นสากล การพัฒนาซอฟต์แวร์จึงง่ายกว่า
ในปี 2545
eBay พัฒนา RESTful API ในปี 2545 โดยเปิดตลาดให้กับเว็บไซต์ใดๆ ที่อาจได้รับประโยชน์จากมัน ด้วยเหตุนี้เอง ยักษ์ใหญ่แห่งอีคอมเมิร์ซอีกรายอย่าง Amazon จึงเริ่มให้ความสนใจ และในปี 2545 ได้เปิดตัว RESTful API
ในปี พ.ศ. 2547–2549
บริการเว็บ RESTful ของ Flickr เปิดตัวในปี 2547 ช่วยให้นักเขียนเพิ่มรูปภาพลงในเว็บไซต์และโพสต์บนโซเชียลมีเดียได้อย่างรวดเร็ว เมื่อ Twitter และ Facebook สังเกตเห็นว่าโปรแกรมเมอร์จำนวนมากกำลังสแกนเว็บไซต์และสร้าง API ของ "Frankenstein" ทั้งคู่ก็เปิดเผย API ของพวกเขาในอีกสองปีต่อมา
ในปี 2549-ปัจจุบัน
ขณะนี้บริการเว็บ RESTful ได้รับการยอมรับอย่างกว้างขวางจากโปรแกรมเมอร์ ซึ่งใช้บริการเว็บ RESTful เหล่านี้เพื่อปรับปรุงประสิทธิภาพของแอปและไซต์ของตน AppMaster อำนวยความสะดวกในการทำงานร่วมกันและทำให้การสร้าง API ง่ายขึ้น ช่วยให้คุณดำเนินการได้รวดเร็วยิ่งขึ้น
REST API ใช้สำหรับอะไร
ข้อดีหลักประการหนึ่งของบริการเว็บ RESTful คือมีความยืดหยุ่นสูง ช่วยให้คุณใช้ RESTful API นี้ได้อย่างมีประสิทธิภาพมากขึ้น ด้านล่างนี้คือตัวอย่าง REST API บางส่วนที่ใช้สำหรับ REST API
แอปพลิเคชันบนคลาวด์
เนื่องจากการเรียกแบบไร้สถานะ REST API จึงได้เปรียบในแอปพลิเคชันระบบคลาวด์ โมดูลไร้สัญชาติสามารถติดตั้งใหม่ได้อย่างง่ายดายและขยายให้ตรงตามความต้องการด้านความจุหากมีสิ่งผิดปกติเกิดขึ้น โปรแกรมซอฟต์แวร์ที่รวมส่วนประกอบภายในเครื่องและบนอินเทอร์เน็ตเป็นแอปพลิเคชันระบบคลาวด์ กระบวนทัศน์นี้ใช้เซิร์ฟเวอร์ที่อยู่ห่างไกลซึ่งเข้าถึงได้โดยเว็บเบราว์เซอร์และบริการอินเทอร์เน็ตบนเว็บที่กำลังดำเนินอยู่เพื่อดำเนินการตามคำแนะนำ
ตำแหน่งดั้งเดิมของโฮสต์แอปพลิเคชันระบบคลาวด์คือระบบคอมพิวเตอร์ระยะไกลที่ดำเนินการโดยผู้ให้บริการเครือข่ายการประมวลผลระบบคลาวด์บุคคลที่สาม จดหมาย การแบ่งปันเอกสารและพื้นที่เก็บข้อมูล การป้อนคำสั่งซื้อ การควบคุมสินค้าคงคลัง Microsoft Word การจัดการความสัมพันธ์กับลูกค้า ( CRM ) การรวบรวมข้อมูล และการเงินและการบัญชี คือตัวอย่างของงานที่ดำเนินการด้วยแอปพลิเคชันบนคลาวด์
อินเทอร์เฟซการเขียนโปรแกรม REST Applications ( API ) สามารถใช้เชื่อมต่อแหล่งข้อมูลภายนอกและทรัพยากรหน่วยเก็บข้อมูล โปรแกรมเมอร์สามารถทำให้แอปบนระบบคลาวด์มีขนาดเล็กลงโดยใช้ REST API เพื่อถ่ายโอนข้อมูลไปยังโปรแกรมอื่นๆ เพื่อจัดการหรือวิเคราะห์การคำนวณและส่งคืนผลลัพธ์ที่ค้นพบไปยังโปรแกรมซอฟต์แวร์ API ที่ผ่านการทดสอบจะบังคับใช้ความสม่ำเสมอแบบแอ็คทีฟ ซึ่งสามารถเร่งการผลิตและให้ผลลัพธ์ที่แท้จริง
ตัวอย่างที่สำคัญของแอปพลิเคชันระบบคลาวด์คือ Google Docs หรือ Office 365 สิ่งที่คุณต้องการสำหรับ Google Docs หรือ Office 365 ก็คือคอมพิวเตอร์ที่สามารถเรียกใช้เครื่องมือค้นหาและบริการเว็บทางอินเทอร์เน็ตได้ เครือข่ายคอมพิวเตอร์มีส่วนต่อประสานกับผู้ใช้และการทำงาน รวมถึงการจัดเก็บข้อมูล บริษัทของคุณสามารถโฮสต์แอประบบคลาวด์ที่แตกต่างกันจำนวนมากได้โดยใช้โฮสต์แอปพลิเคชันระบบคลาวด์
บริการคลาวด์
เนื่องจากคุณต้องจัดการวิธีการประมวลผล URL เพื่อเชื่อมต่อกับทรัพยากรผ่าน API ดังนั้น REST API จึงมีประโยชน์สำหรับบริการเว็บบนคลาวด์ด้วย สถาปัตยกรรมบริการเว็บ RESTful มีแนวโน้มว่าจะกลายเป็นมาตรฐานในอนาคตเนื่องจากแอปพลิเคชันระบบคลาวด์ โปรแกรมเมอร์ใช้บริการเว็บ RESTful เพื่อเชื่อมต่อกับบริการคลาวด์โดยใช้อินเทอร์เน็ต นักพัฒนาสร้างโค้ดที่ใช้ API ของผู้ให้บริการอินเทอร์เน็ต ป้อนข้อมูลและตัวแปรที่จำเป็น จากนั้นตรวจสอบคำตอบเพื่อให้แน่ใจว่าการดำเนินการเป็นไปตามที่คาดไว้
ผู้ใช้ปลายทางสามารถเข้าถึงแอปพลิเคชันไคลเอ็นต์หรือบริการบนเว็บที่นำเสนอโดยบริการเว็บบนคลาวด์ เช่น โครงสร้างพื้นฐานด้านการคำนวณ ระบบจัดเก็บข้อมูล หรือระบบติดตาม โดยใช้บริการคลาวด์ เช่น บริการเว็บ RESTful API แสดงความสามารถและการดำเนินการของแอปพลิเคชันและข้อมูลเฉพาะที่จำเป็นในการดำเนินการ เพื่อรักษาความเป็นส่วนตัวและความปลอดภัยของไคลเอ็นต์ API มักจะขึ้นอยู่กับการทำงานร่วมกันของ REST หรือ Simple Object Access Protocol (SOAP) และกลไกการอนุญาต เช่น OAuth 2.0
บริการเว็บที่หลากหลายเรียกว่า "บริการคลาวด์" และให้บริการแก่ธุรกิจและผู้บริโภคทางออนไลน์ตามคำขอ บริการบนเว็บเหล่านี้สร้างขึ้นเพื่อให้เข้าถึงเครื่องมือและแอปได้อย่างรวดเร็วและราคาไม่แพง โดยไม่ต้องใช้ฮาร์ดแวร์หรือโครงสร้างพื้นฐาน พนักงานส่วนใหญ่ใช้บริการเว็บคลาวด์สำหรับทุกอย่างตั้งแต่อีเมลไปจนถึงการทำงานร่วมกันในเอกสาร
การใช้งานเว็บ
Web API เหล่านี้สามารถรับได้จากโครงการเว็บของผู้ใช้ แอป iPhone อุปกรณ์ IoT หรือ Windows Mobile เนื่องจาก REST ไม่ได้ขึ้นอยู่กับฟังก์ชันฝั่งไคลเอ็นต์ คุณสามารถสร้างสถาปัตยกรรมสำหรับธุรกิจของคุณโดยไม่ถูกจำกัดให้อยู่ในกรอบฝั่งไคลเอ็นต์เฉพาะ
ตัวอย่าง REST API
เรามาพูดถึงตัวอย่าง REST API กัน คลิกลิงก์ด้านล่างเพื่อสอบถาม Open Trivia Database เพื่อสอบถามข้อมูลข่าวกรองตามอำเภอใจ: บริการเว็บ RESTful ดังกล่าวถูกใช้เพื่อให้บริการ API เว็บสาธารณะ คอมพิวเตอร์ของคุณจะแสดงคำถามแบบทดสอบเดียวและคำตอบในรูปแบบ JSON
เมื่อใช้เบราว์เซอร์ HTTP เช่น url คุณอาจใช้ข้อความค้นหาต่อไปนี้และรับการตอบกลับในเนื้อหาการตอบกลับ: https://opentdb.com/api.php?amount=1&category=18
เนื้อหาการตอบสนองของไฟล์ XML ของบริการเว็บจะมีข้อมูลของพนักงานทั้งหมด
ภาษาในการเขียนโปรแกรมและเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่ใช้กันอย่างแพร่หลายทั้งหมดมีไลบรารีไคลเอนต์ HTTP เช่น การดึงข้อมูลใน JavaScript, Node.js และ Deno และไฟล์รับเนื้อหา () ใน PHP คำตอบ JSON สามารถอ่านและใช้งานได้เนื่องจากสามารถอ่านด้วยเครื่องได้ก่อนที่จะแสดงในรูปแบบ HTML หรือรูปแบบอื่น
API ส่วนที่เหลือและ REST
เมื่อเวลาผ่านไป วิธีการรับส่งข้อมูลได้พัฒนาขึ้นมากมาย คุณอาจเจอตัวเลือกต่างๆ เช่น CORBA, SOAP หรือ XML-RPC หลักเกณฑ์เกี่ยวกับข้อความเข้มงวดที่ได้รับการพัฒนามากที่สุด Roy Fielding กล่าวถึง REST เป็นครั้งแรกในปี 2000 ซึ่งตรงไปตรงมามากกว่าเรื่องอื่นๆ
เป็นการรวบรวมคำแนะนำและข้อจำกัดสำหรับบริการเว็บ RESTful มากกว่าจะเป็นบรรทัดฐาน ประกอบด้วยข้อจำกัดทางสถาปัตยกรรมดังต่อไปนี้:
พาร์ติชันไคลเอนต์เซิร์ฟเวอร์
ไคลเอ็นต์และเว็บเซิร์ฟเวอร์สามารถสื่อสารในทิศทางเดียวเท่านั้นภายใต้สถาปัตยกรรม REST: ไคลเอ็นต์ร้องขอตัวควบคุมโดเมน และตัวควบคุมหรือเซิร์ฟเวอร์ตอบสนองคำขอ เว็บเซิร์ฟเวอร์ไม่สามารถส่งคำขอได้ และลูกค้าไม่สามารถตอบสนองได้ ผู้บริโภคเริ่มการเชื่อมต่อทั้งหมด
บริการบนเว็บ RESTful ทำให้ลูกค้าและเซิร์ฟเวอร์แยกจากกันโดยการลดการโต้ตอบระหว่างกัน คอมพิวเตอร์ไคลเอ็นต์สามารถพัฒนาได้โดยไม่ต้องกลัวว่าจะส่งผลกระทบต่อโฮสติ้งอื่น และวัสดุของเซิร์ฟเวอร์สามารถเปลี่ยนแปลงได้โดยไม่ส่งผลกระทบต่อลูกค้าโดยไม่เจตนา
อินเตอร์เฟซที่สม่ำเสมอ
ตามกลยุทธ์นี้ ข้อความค้นหาและปฏิกิริยาทั้งหมดต้องเป็นไปตามขั้นตอนโพรเว็บมาตรฐานหรือจัดรูปแบบข้อความ แอปและเซิร์ฟเวอร์ได้รับการพัฒนาในภาษาการเขียนโปรแกรมต่างๆ ซึ่งทำงานร่วมกันได้ไม่ดีโดยมีสื่อกลาง อินเทอร์เฟซแบบเดียวกันคือภาษาถิ่นที่ลูกค้าสามารถใช้โต้ตอบกับ REST API ใดๆ ได้
การแปลคำขอและการตอบสนองระหว่างแอปพลิเคชันที่มีการโต้ตอบแบบปกติจะเป็นไปได้เท่านั้น ความแตกต่างเล็กน้อยอาจทำให้ข้อมูลผิดพลาดและสูญเสียข้อมูล และโซลูชันจะต้องอัปเกรดขั้นตอนการร้องขอเมื่อ API ของเว็บปรับเปลี่ยน อินเทอร์เฟซที่สอดคล้องกันช่วยขจัดโอกาสนี้
เข้าถึง https://www.googleapis.com/youtube/v3/channels?part=contentDetails
เช่นเดียวกับแอปพลิเคชัน REST Client ทั้งหมด ข้อเสนอนี้มีข้อมูลสองส่วน เทคนิค HTTP คือ GET สิ่งนี้อธิบายการดำเนินการที่ไคลเอ็นต์ต้องการใช้ทรัพยากร ผู้ใช้สามารถสร้างวิธี HTTP พื้นฐานได้สี่วิธี:
HTTP หรือ Hyper-Text Transfer Protocol เป็นภาษาสากลสำหรับ REST API ส่วนใหญ่ HTTP ไม่ได้ออกแบบโดยคำนึงถึง REST นอกจากนี้ REST ยังยอมรับการส่งข้อมูลนี้เป็นเกณฑ์สำหรับแอปที่รับรู้ REST สำหรับการใช้ HTTP กับ REST API ไคลเอ็นต์จะส่งคำขอในรูปแบบที่คุณอาจคุ้นเคย ตัวอย่างเช่น สัญญาณวิดีโอร้องขอ YouTube API มีลักษณะดังนี้:
- ใช้คำสั่ง GET เพื่อรับทรัพยากร
- ใช้คำสั่ง POST เพื่อสร้างทรัพยากรใหม่
- ใช้คำสั่ง PUT เพื่อเปลี่ยนแปลงหรืออัปเดตทรัพยากรที่มีอยู่ต่อไป
- ใช้คำขอ DELETE เพื่อกำจัดทรัพยากร
เมธอด HTTP ระบุการดำเนินการที่ตั้งใจจะดำเนินการเกี่ยวกับทรัพยากรเฉพาะ เมธอด HTTP เรียกอีกอย่างว่ากริยา HTTB
URL คือ HTTP
ตัวระบุทรัพยากรแบบเดียวกันหรือ URI ที่ระบุทรัพยากรที่ต้องการมีอยู่ใน URL นอกจากนี้ URL ยังเป็นจุดสิ้นสุดในสถานการณ์นี้เนื่องจากเป็นจุดที่ RESTful API ติดต่อกับผู้ใช้บริการ
สตริงข้อความค้นหา: URL รวมสตริงข้อความค้นหา สตริงการสืบค้นใช้เพื่อกำหนดพารามิเตอร์ซึ่งได้รับค่า
หลังจากได้รับและยืนยันคำร้องแล้ว เว็บเซิร์ฟเวอร์จะคืนข้อมูลในทรัพยากรเป้าหมาย โดยทั่วไป ข้อมูลจะถูกส่งกลับในโครงสร้างที่เรียกว่า JSON (JavaScript Object Notation) JSON นำเสนอส่วนประกอบทั้งหมดของทรัพยากรในรูปแบบพกพาที่มนุษย์สามารถอ่านได้ง่าย
หลักการของส่วนต่อประสานแบบเดียวกัน
อินเทอร์เฟซแบบเดียวกันต้องเป็นไปตามพารามิเตอร์ต่อไปนี้:
HATEOAS: ไฮเปอร์มีเดียเป็นเครื่องมือของสถานะแอปพลิเคชัน
ไฮเปอร์มีเดียเป็นเครื่องมือที่อยู่เบื้องหลังบริการเว็บ RESTful สิ่งนี้บ่งชี้ว่าไฮเปอร์มีเดียคือทุกสิ่งที่ลูกค้าต้องการเข้าใจเพื่อรับรู้คำตอบของผู้ให้บริการ
- ต้องระบุเฉพาะ URI แรกของแอปพลิเคชันไคลเอนต์แก่ไคลเอ็นต์เท่านั้น แอปพลิเคชันไคลเอนต์ควรขับเคลื่อนเนื้อหาและกิจกรรมอื่นๆ ทั้งหมดอย่างต่อเนื่องโดยใช้ไฮเปอร์ลิงก์
- บริการบนเว็บ RESTful ไม่ต้องการภาษาคิวรีอินพุต (IDL) ซึ่งแตกต่างจาก API อื่นๆ
ประเภทสื่อคือชื่อสำหรับรูปแบบข้อมูลของตัวแทน ประเภทสื่อจะระบุคำจำกัดความที่สรุปว่าควรปฏิบัติต่อการแสดงภาพอย่างไร Web API ที่ใช้ REST ดูเหมือนไฮเปอร์เท็กซ์ รายการข้อมูลทุกรายการที่อาจระบุตำแหน่งได้ ไม่ว่าจะโดยตรง (เช่น ผ่านลิงก์และคุณสมบัติข้อมูลประจำตัว) หรือโดยปริยาย (เช่น มาจากโครงสร้างคำอธิบายประเภทสื่อ)
ข้อความอธิบายตนเอง
การสื่อสารแต่ละครั้งระหว่างฝั่งไคลเอนต์และฝั่งเซิร์ฟเวอร์ควรให้ข้อมูลที่เพียงพอเพื่อดำเนินการสื่อสาร ดังนั้น คำขอจากฝั่งไคลเอ็นต์ไปยังฝั่งเซิร์ฟเวอร์จำเป็นต้องระบุทรัพยากรที่พยายามเข้าถึงพร้อมกับเป้าหมายเฉพาะ
นอกจากนี้ การพรรณนาทรัพยากรจะต้องสื่อความหมายในตัวมันเอง ผู้ใช้ไม่จำเป็นต้องทราบว่าทรัพยากรเป็นบุคคลหรือชิ้นส่วนของอุปกรณ์ ควรตอบสนองตามประเภทสื่อที่เชื่อมต่อกับวิธีใช้แทน
ดังนั้น ไม่ต้องสงสัยเลยว่าเราจะพัฒนาสื่อประเภทต่างๆ ที่ไม่ซ้ำกัน ซึ่งมักจะเป็นสื่อประเภทเดียวต่อทรัพยากร สื่อทุกรูปแบบกำหนดรูปแบบการผลิตมาตรฐาน ตัวอย่างเช่น HTML กำหนดวิธีการแสดงไฮเปอร์เท็กซ์และวิธีที่เบราว์เซอร์จัดการกับส่วนประกอบแต่ละส่วนการระบุทรัพยากร
ทรัพยากรที่อ้างถึงในการสื่อสารด้านหลังระหว่างลูกค้าและเซิร์ฟเวอร์จะต้องสามารถจดจำได้โดยใช้การพรรณนา การยึดติดกับระบบ Uniform Resource Identifier (URI) อนุญาตสำหรับสิ่งนี้ กล่าวอีกนัยหนึ่ง การสื่อสารจากเซิร์ฟเวอร์ไปยังลูกค้าอาจรวมถึงเอกสารเวอร์ชัน HTML และข้อมูลบางอย่าง แทนที่จะเป็นไฟล์จริงจากที่เก็บข้อมูลของเซิร์ฟเวอร์
ผู้บริโภคสามารถเข้าใจเวอร์ชัน HTML ได้อย่างง่ายดายเนื่องจากเป็นไปตามรูปแบบ URI ลูกค้าต้องแก้ไขทรัพยากรโดยให้เซิร์ฟเวอร์บรรยายว่าทรัพยากรควรปรากฏอย่างไรในท้ายที่สุด สิ่งนี้จะทำให้ผู้ใช้สามารถสร้าง เรียกค้น แก้ไข และลบทรัพยากร หากลูกค้ามีสิทธิ์ที่จำเป็นในการเปลี่ยนแปลงข้อมูล เซิร์ฟเวอร์ควรทำตามคำขอ
ไร้สัญชาติ
ด้วย RESTful API คำขอของไคลเอ็นต์ทั้งหมดจะต้องเป็นแบบชั่วคราว ด้วยเหตุนี้ เนื้อหาการสอบถามและการตอบสนองแต่ละรายการจึงรวมข้อมูลทั้งหมดที่จำเป็นในการสรุปสัญญา ทำให้การเชื่อมต่อแต่ละครั้งเป็นไปอย่างอิสระ เซิร์ฟเวอร์ไม่ติดตามคำขอ HTTP ก่อนหน้า จะถือว่าแต่ละรายการที่สร้างโดยลูกค้าเป็นการสืบค้นใหม่ทั้งหมด
เนื่องจากเซิร์ฟเวอร์ไม่ต้องทำงานพิเศษใดๆ เพื่อรับข้อมูลประวัติ การขนส่งแบบไร้สัญชาติจะลดจำนวนพื้นที่จัดเก็บที่จำเป็นสำหรับเซิร์ฟเวอร์ลงอย่างมาก และเพิ่มโอกาสที่การตอบสนองจะยอมรับได้ สิ่งนี้รับประกันความสามารถในการปรับขนาดของการโต้ตอบเหล่านี้: โปรแกรมเมอร์ไม่ต้องกังวลเกี่ยวกับการใช้พื้นที่เก็บข้อมูลมากขึ้นหรือการเก็บภาษีเซิร์ฟเวอร์เมื่อซอฟต์แวร์ของพวกเขาขยายและสร้างคำขอ HTTP
ชั้น
จนถึงตอนนี้เราได้กำหนดให้การสืบค้นเว็บ API เป็นการแลกเปลี่ยนระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ที่ตรงไปตรงมา แม้ว่าสิ่งนี้จะทำให้ง่ายเกินไปเล็กน้อย ระหว่างสององค์กรนี้มักจะมีเซิร์ฟเวอร์มากกว่า แพลตฟอร์มหรือเลเยอร์เหล่านี้มีไว้เพื่อจัดการและกระจายทราฟฟิก เพิ่มการป้องกัน และปฏิบัติงานที่สำคัญอื่นๆ อีกมากมาย
ตามแนวคิดนี้ ข้อความที่ส่งระหว่างผู้ใช้และเซิร์ฟเวอร์เป้าหมายจะต้องมีโครงสร้างและจัดการในลักษณะเดียวกัน โดยไม่คำนึงถึงเลเยอร์ที่อยู่ระหว่างนั้น เลเยอร์พิเศษควรใช้ได้กับการโต้ตอบกับลูกค้า โปรแกรมเมอร์ที่ปฏิบัติตามกฎนี้สามารถเปลี่ยนระบบเซิร์ฟเวอร์ได้โดยไม่ส่งผลกระทบต่อกระบวนการตอบสนองคำขอพื้นฐาน
แคชได้
การแคชเกิดขึ้นเมื่อลูกค้าเรียกดูเว็บไซต์เมื่อเนื้อหาถูกบันทึกไว้ในเครื่องของลูกค้า เนื้อหาที่แคชจะถูกโหลดอย่างรวดเร็วจากหน่วยความจำภายใน แทนที่จะดาวน์โหลดอีกครั้งจากเซิร์ฟเวอร์เมื่อผู้ใช้เยี่ยมชมไซต์นั้นในภายหลัง ไซต์ขนาดใหญ่ส่วนใหญ่ใช้การแคชเพื่อลดการโหลดหน้าเว็บในขณะที่รักษาพื้นที่เซิร์ฟเวอร์และแบนด์วิธ
การแคชข้อมูลได้รับการพิจารณาเมื่อพัฒนา REST API การตอบสนองที่เซิร์ฟเวอร์ให้กับลูกค้าควรระบุว่าสามารถจัดเก็บทรัพยากรที่กำหนดได้หรือไม่และมากเพียงใด
ในรหัสความต้องการ
หลักการ REST สุดท้ายไม่จำเป็น หากมีการร้องขอ การตอบสนองของ API สามารถรวมรหัสซอฟต์แวร์เพื่อให้ไคลเอ็นต์ใช้ ด้วยเหตุนี้ ลูกค้าจึงสามารถเรียกใช้แอปพลิเคชันไคลเอ็นต์หรือโปรแกรมในส่วนหลังได้
API จะถือว่าเป็น RESTful API หากเป็นไปตามหลักเกณฑ์ชุดนี้ อย่างไรก็ตาม หลักเกณฑ์เหล่านี้ให้อิสระแก่โปรแกรมเมอร์ในการปรับเปลี่ยนคุณลักษณะของ RESTful API REST API แตกต่างจาก Simple Object Access Protocol ซึ่งเป็นเทคนิค Web API ที่ได้รับความนิยมอีกรูปแบบหนึ่ง โดยมีความยืดหยุ่นมากกว่า (SOAP)
ฉันทามติปลายทาง
คำนึงถึงจุดสิ้นสุดเหล่านี้:
- /user/123\s
- /user/id/123\s
- /user/123\s/user/id/123\s
- /user/?id=123
ทั้งหมดเป็นวิธีการที่ถูกต้องตามกฎหมายสำหรับลูกค้า 123 ในการดึงข้อมูล เมื่อมีขั้นตอนที่ซับซ้อนมากขึ้น จำนวนความเป็นไปได้ก็เพิ่มขึ้น ตัวอย่างเช่น ในลำดับย้อนกลับที่เริ่มต้นที่รายการ 51 แสดง 10 คนที่มีนามสกุลที่ขึ้นต้นด้วย "A" และทำงานให้กับบริษัท
ท้ายที่สุดแล้ว มันไม่ได้สนใจว่าคุณจัดโครงสร้าง URL อย่างไร ความสม่ำเสมอตลอดทั้ง RESTful API ของคุณมีความสำคัญ ในระบบซอฟต์แวร์ขนาดใหญ่ที่มีโปรแกรมเมอร์มากมายนั้นไม่ใช่เรื่องง่าย การแก้ไข RESTful API เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่ URL ปลายทางต้องไม่ถูกปฏิเสธ เพราะการทำเช่นนั้นจะทำให้แอปที่อาศัย URL ดังกล่าวหยุดทำงาน
การกำหนดเวอร์ชัน REST API
การกำหนดเวอร์ชัน API เป็นวิธีปฏิบัติทั่วไปเพื่อป้องกันความเข้ากันไม่ได้ ตามภาพประกอบ /2.0/user/123 จะแทนที่ /user/123 ปลายทางเก่าและใหม่สามารถทำงานต่อไปได้ ด้วยเหตุนี้จึงจำเป็นต้องบำรุงรักษา API ที่สำคัญในอดีต เวอร์ชันก่อนหน้าสามารถเลิกใช้งานได้ในท้ายที่สุด แต่กระบวนการจะต้องได้รับการพิจารณาอย่างรอบคอบ
การรับรองความถูกต้องของ REST API
อุปกรณ์ใด ๆ สามารถดาวน์โหลด quip โดยไม่ได้รับอนุญาตโดยใช้ API การสอบถาม API ที่อ่านข้อมูลส่วนตัวหรืออนุญาตให้แก้ไขและลบข้อความค้นหาไม่รองรับสิ่งนี้ โปรแกรมฝั่งไคลเอ็นต์ภายในโดเมนเดียวกับบริการเว็บ RESTful จะส่งและรับคุกกี้ในลักษณะเดียวกับคำขอ HTTP (โปรดทราบว่าต้องระบุตัวเลือกการรีสตาร์ทสิทธิ์ในเว็บไซต์ก่อนหน้านี้สำหรับ Fetch()) สามารถตรวจสอบการสืบค้น API เพื่อยืนยันว่าผู้ใช้ลงชื่อเข้าใช้และมีสิทธิ์ที่จำเป็น
การรับรองความถูกต้องพื้นฐาน HTTP : โปรแกรมของบุคคลที่สามต้องใช้โซลูชันการอนุมัติที่แตกต่างกัน วิธีการรับรองความถูกต้องที่เป็นที่นิยมบางวิธีคือการตรวจสอบเบื้องต้นสำหรับ:
- เอชทีทีพี ชื่อผู้ใช้ที่เข้ารหัส base64: สตริง รหัสผ่าน จะได้รับในฟิลด์ข้อความค้นหาซึ่งเป็นส่วนหนึ่งของส่วนหัวการอนุมัติ HTTP
- คีย์ API: โดยการจัดเตรียมคีย์ RESTful API ที่อาจมีสิทธิ์พิเศษหรือจำกัดไว้ที่ไซต์เดียว API จะพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม แต่ละข้อความมีคีย์ในสตริงข้อความค้นหาหรือในส่วนหัว HTTP (สตริงข้อความค้นหาเป็นส่วนประกอบของ URL)
- OAuth: ก่อนที่จะส่งคำขอใด ๆ รหัสลูกค้าและรหัสลับของลูกค้าจะถูกส่งไปยังเซิร์ฟเวอร์ OAuth เพื่อรับข้อมูลประจำตัว ข้อมูลประจำตัว OAuth จะถูกส่งไปพร้อมกับคำขอ API แต่ละรายการจนกว่าจะหมดอายุ
- โทเค็นอินเทอร์เน็ตใน JSON (JWT): ส่วนหัวของแบบสอบถามและส่วนหัวของการตอบสนองจะส่งข้อมูลรับรองผู้ใช้ที่เซ็นชื่อแบบดิจิทัลอย่างปลอดภัย JWT ช่วยให้เซิร์ฟเวอร์เข้ารหัสสิทธิ์การเข้าถึง ไม่จำเป็นต้องสอบถามฐานข้อมูลหรือใช้กลไกการตรวจสอบสิทธิ์อื่น
สถานการณ์การใช้งานจะส่งผลต่อการตรวจสอบความถูกต้องของ API:
- บางครั้งโปรแกรมของบุคคลที่สามจะได้รับการจัดการเช่นเดียวกับไคลเอนต์ที่เข้าสู่ระบบอื่น ๆ ที่มีสิทธิ์และสิทธิ์เหมือนกัน ตัวอย่างเช่น map API อาจให้โปรแกรมที่ร้องขอพร้อมคำแนะนำระหว่างจุดสองจุด ต้องตรวจสอบว่าโปรแกรมเป็นผู้ใช้ที่ถูกต้องตามกฎหมาย แต่ไม่จำเป็นต้องตรวจสอบข้อมูลรับรองของลูกค้า
- ในสถานการณ์อื่นๆ โปรแกรมของบุคคลที่สามจะขอข้อมูลส่วนบุคคลจากผู้ใช้เฉพาะ เช่น เนื้อหาอีเมล REST API ต้องรู้จักไคลเอ็นต์และสิทธิ์ แต่ไม่จำเป็นต้องเกี่ยวข้องกับโปรแกรมการโทร
ความปลอดภัยของ REST API
บริการบนเว็บ RESTful เพิ่มวิธีเพิ่มเติมในการโต้ตอบและมีอิทธิพลต่อซอฟต์แวร์ของคุณ แม้ว่าโฮสต์ของคุณจะไม่ใช่เป้าหมายการแฮ็คขั้นสูง แต่ผู้ใช้ที่ประพฤติตัวไม่เหมาะสมสามารถส่งคำขอหลายร้อยรายการต่อวินาทีและยุบคำขอนั้น บทความนี้ไม่ครอบคลุมถึงความปลอดภัย แต่ขั้นตอนมาตรฐานที่ดีที่สุดเกี่ยวข้องกับ:
ใช้ HTTPS
ใช้กลไกการรับรองความถูกต้องที่รัดกุม
สามารถใช้ CORS เพื่อจำกัดการโทรของลูกค้าไปยังพื้นที่เฉพาะได้
จัดหาสิ่งจำเป็นของความสามารถ — นั่นคือไม่
สร้างตัวเลือก DELETE ที่ไม่จำเป็น ตรวจสอบ URL ปลายทางและข้อมูลเนื้อหาทั้งหมด
บล็อกลิงก์จากส่วนที่ไม่ปรากฏชื่อหรือที่อยู่ IP โดยไม่ใช้ API สำคัญใน JavaScript ฝั่งไคลเอ็นต์
แพ็กเก็ตขนาดใหญ่ผิดปกติถูกบล็อก
ลองนึกถึงการจำกัดอัตรา ซึ่งคำขอจากที่อยู่ IP หรือข้อมูลรับรอง API เดียวกันจะถูกจำกัดไว้ที่ N ข้อความค้นหาต่อนาที
การตอบสนองด้วยรหัสสถานะ HTTP ที่เหมาะสม การสืบค้นบันทึกส่วนหัวของแคช และการตรวจสอบที่ไม่สำเร็จ
คำขอหลายรายการและข้อมูลที่ไม่จำเป็น
การใช้บริการเว็บ RESTful มีข้อจำกัด อาจเป็นไปได้ว่าการตอบกลับมีข้อมูลมากกว่าที่คุณร้องขอ หรือต้องมีคำขอหลายรายการเพื่อให้ได้ข้อมูลทั้งหมด ลองนึกถึงบริการเว็บ RESTful ที่ให้ผู้ใช้เข้าถึงข้อมูลผู้สร้างและหนังสือ ลูกค้าสามารถ:
- สอบถามข้อมูลหนังสือ 10 เล่มแรก เรียงตามลำดับการสั่งซื้อ (ขายดีก่อน) รวมหนังสือพร้อม ID นักเขียนแต่ละคนไว้ในคำตอบ
หากต้องการดึงข้อมูลสำหรับผู้เขียนแต่ละคน ให้สร้าง /author/id มากถึง 10 รายการ
ควรสร้างการสืบค้น N API สำหรับการตอบสนองต่อการสืบค้นพาเรนต์แต่ละครั้ง ซึ่งมีลักษณะเป็น "ปัญหา N+1"
หากนี่เป็นสถานการณ์ที่ใช้งานบ่อย บริการเว็บ RESTful อาจได้รับการแก้ไขเพื่อรวมข้อมูลนักเขียนทั้งหมดสำหรับหนังสือทุกเล่มที่ผลิต รวมถึงชื่อ เพศ สัญชาติ ชีวประวัติ และอื่นๆ อาจมีการให้ข้อมูลเพิ่มเติมเกี่ยวกับหนังสือเล่มก่อนๆ แม้ว่าการทำเช่นนั้นจะเพิ่มภาระการตอบกลับอย่างมาก API อาจมีการเปลี่ยนแปลงเพื่อให้ข้อมูลผู้เขียนเป็นตัวเลือก รายละเอียดผู้แต่ง = เต็ม เพื่อป้องกันคำตอบใหญ่โดยไม่จำเป็น ตัวเลือกจำนวนมากที่ผู้ออกแบบ API ต้องรองรับอาจมากเกินไป
ห่อ
ตอนนี้คุณเข้าใจ REST API อย่างละเอียด วิธีการทำงานของ REST API ตัวอย่าง REST API สิ่งที่ใช้ REST API ข้อจำกัดทางสถาปัตยกรรม และหัวข้ออื่นๆ ที่ครอบคลุมในบทช่วยสอนนี้ โปรแกรมเมอร์อาจพบว่าการเรียนรู้เกี่ยวกับ API นั้นยากและน่ากลัว แต่ AppMaster แพลตฟอร์ม ที่ไม่มีโค้ด ได้สร้างไลบรารี REST APIs ใหม่ที่เข้าถึงได้ ซึ่งคุณสามารถเพิ่มการรับรู้เกี่ยวกับ REST APIs ต่างๆ เพื่อสนับสนุนการพัฒนาวิชาชีพต่อไปของคุณ
ที่ AppMaster เราพยายามเพิ่มการเข้าถึงและความสามารถในการใช้งาน API เราต้องการให้คุณเรียนรู้ ทดลอง และตระหนักถึงประโยชน์ของการใช้ซอฟต์แวร์ API ในอาชีพการงานและชีวิตส่วนตัวของคุณ เพื่อช่วยให้คุณออกแบบเว็บ API ที่ดีขึ้นได้เร็วขึ้น AppMaster ปรับปรุงการทำงานร่วมกันและทำให้ทุกขั้นตอนของวงจรชีวิต API เป็นไปโดยอัตโนมัติ สร้าง พัฒนา และขยายความเข้าใจเกี่ยวกับ REST API ของคุณต่อไป