คำขอ API ภายนอก

ทฤษฎีไม่มากเกินไป?

ลองนำสิ่งนี้ไปปฏิบัติ มาเปิด AppMaster สร้างคำขอ API โดยใช้มัน และทำความเข้าใจเกี่ยวกับวิธีการทำงานของคำขอนี้ให้ดียิ่งขึ้น

การสร้างคำขอ API ภายนอก

คำขอ API ถูกสร้างขึ้นในส่วน "ตรรกะทางธุรกิจ" ในแท็บ "คำขอ API ภายนอก"

ได้เวลาคลิก “+ คำขอ API ใหม่”

ชื่อและคำอธิบายสามารถตั้งเป็นอะไรก็ได้ มีไว้สำหรับใช้ส่วนตัวเท่านั้น

มาจัดการกับข้อมูลที่สำคัญจริงๆ กันเถอะ

ขั้นต่ำที่จำเป็นในการสร้างคำขอคือการระบุวิธีการและที่อยู่ (URL) เริ่มจากอันสุดท้ายกันก่อน

URL

URL - ตัวระบุตำแหน่งทรัพยากรแบบเดียวกัน ที่อยู่ที่กำหนดให้กับแหล่งข้อมูลเฉพาะบนอินเทอร์เน็ต ทรัพยากรดังกล่าวในเวอร์ชันที่คุ้นเคยที่สุดคือหน้า HTML - เราป้อน URL ในแถบที่อยู่ของเบราว์เซอร์และเปิดไซต์ที่ต้องการ ในเวลาเดียวกัน ทรัพยากรสามารถเป็นอะไรก็ได้ รูปภาพ วิดีโอ ชุดข้อมูล สิ่งสำคัญคือทรัพยากรนี้มีตัวชี้เฉพาะ - URL ที่คุณสามารถส่งคำขอเพื่อรับทรัพยากรนี้ได้

วิธีการ

เรายังระบุวิธีการ (คุณสามารถระบุประเภท) ของคำขอด้วยการอ้างอิงถึงข้อมูลที่อยู่ของมัน นั่นคือเราระบุสิ่งที่ต้องทำจริงกับข้อมูลนี้

เมื่อเราส่งคำขอสำหรับงานของโมดูลแรก เราได้รับข้อมูล นี่คือวิธี GET วิธีนี้เป็นวิธีที่ชัดเจนที่สุดและเป็นวิธีเดียวที่จำเป็น ดังนั้น แม้ว่าเราจะไม่ได้ระบุอย่างชัดเจน แต่ก็ยังสันนิษฐานตามค่าเริ่มต้นว่านี่คือ GET

มาดูกันว่ามีวิธีไหนอีกบ้าง

มาตรฐาน HTTP นั้นไม่ได้จำกัดจำนวนเมธอดที่สามารถใช้ได้ ในเวลาเดียวกัน มีเพียงวิธีการมาตรฐานบางส่วนเท่านั้นที่ยังคงใช้เพื่อรักษาความเข้ากันได้ มี 5 วิธีที่แตกต่างกันที่สามารถใช้ในคำขอ AppMaster API

รับ มันจัดการเรียบร้อยแล้ว เมธอดร้องขอการจัดหาทรัพยากรและรับข้อมูล

โพ สต์ หากต้องการนำข้อมูลจากที่ใดที่หนึ่ง คุณต้องวางข้อมูลนี้ไว้ที่นั่นก่อน วิธี POST ทำเช่นนั้น ส่งข้อมูลไปยังเซิร์ฟเวอร์ สร้างทรัพยากร

ใส่ . คล้ายกับวิธี POST แต่หน้าที่ของมันคือการปรับปรุงข้อมูล มันไม่ได้สร้างข้อมูลใหม่ แต่แทนที่ข้อมูลที่มีอยู่ ปรับปรุงมัน

ลบ ตามชื่อที่แนะนำ มันจะลบข้อมูล

แพ ทช์ วิธีนี้คล้ายกับ PUT แต่ใช้เพื่ออัปเดตข้อมูลเพียงบางส่วน แทนที่จะแทนที่ทั้งหมด ตัวอย่างเช่น ใช้เมธอด PATCH คุณสามารถเปลี่ยนชื่อบทความ หรือเปลี่ยนค่าของพารามิเตอร์บางตัวได้

สิ่งสำคัญคือต้องพิจารณาความจริงที่ว่าเซิร์ฟเวอร์ไม่จำเป็นต้องทำสิ่งที่ระบุไว้ในวิธีการทั้งหมด เราสามารถส่งที่อยู่ของบางหน้าด้วยวิธี DELETE แต่ไม่ได้หมายความว่าเซิร์ฟเวอร์จะลบออกจริง แต่ในทางทฤษฎี เขาสามารถทำได้ด้วยคำสั่ง GET หรือไม่ต้องเปลี่ยนแปลงอะไร แต่ในขณะเดียวกันก็ส่งข้อมูลตอบกลับไปยัง POST เพียงเพราะผู้พัฒนากำหนดค่าด้วยวิธีนั้น

นี่คือสิ่งที่ REST เข้ามามีบทบาท ซึ่งบอกว่าถึงเวลาที่จะต้องยอมรับการปฏิบัติตามคำสั่ง หยุดความยุ่งเหยิง และทำสิ่งที่ระบุไว้ในวิธีการ อย่างน้อยที่สุด ควรเป็นงานหลัก (แม้ว่าจะไม่ใช่งานเดียวก็ตาม) เช่น เมื่อถ่ายโอนเนื้อหาของบทความโดยใช้เมธอด GET คุณสามารถเพิ่มตัวนับจำนวนการดูได้ 1 ในเวลาเดียวกัน

ดังนั้นเราจึงทราบว่าข้อมูลนั้นอยู่ที่ใดและจะทำอะไรได้บ้าง ต่อไปมาดูกันว่าส่วนประกอบอื่น ๆ ที่ร้องขอสามารถมีได้

พารามิเตอร์ URL

พารามิเตอร์ URL มีบางสถานการณ์ที่เรารู้จัก URL เพียงบางส่วนเท่านั้น ตัวอย่างคือบทความบนเว็บไซต์ Appmaster.io ที่อยู่เริ่มต้นสำหรับบทความทั้งหมดเหมือนกัน - https://appmaster.io/blog/ แต่แล้วแต่ละบทความก็มีชื่อเรื่องของตัวเอง ดังนั้น จึงมีแต่ละส่วนของมันเองเพื่อบ่งบอกถึงบทความนี้โดยเฉพาะ

ในสถานการณ์ดังกล่าว จะใช้พารามิเตอร์ URL เรากำหนดส่วนทั่วไปทันทีและปล่อยให้ส่วนที่เหลืออยู่ในกระบวนการตัดสินใจ ด้วยเหตุนี้ URL จึงเขียนในรูปแบบ https://appmaster.io/blog/:id/

ส่วนที่ทราบจะเขียนตามที่เป็น และส่วนที่แปรผันจะอยู่หลังเครื่องหมาย “:” ชื่อของส่วนตัวแปรนี้ (ไม่มี ":" แล้ว) จะถูกเพิ่มในรายการพารามิเตอร์ ในกรณีนี้ อาจมีตัวแปรได้หลายส่วน และตำแหน่งจะอยู่ที่ใดก็ได้ใน URL

พารามิเตอร์แบบสอบถาม

พารามิเตอร์แบบสอบถาม จำตอนที่เราส่งคำขอไปที่ boredapi.com ในโมดูลแรกได้ไหม และนอกเหนือจากที่อยู่แล้วยังมีการกำหนดข้อมูลเพิ่มเติม นั่นคือ Query Params

โดยเขียนตามหลัง URL และคั่นด้วย "?" เข้าสู่ระบบ. มีการระบุชื่อของพารามิเตอร์ เครื่องหมาย “=” และค่าของพารามิเตอร์เอง หากใช้หลายพารามิเตอร์พร้อมกัน พารามิเตอร์เหล่านั้นจะถูกคั่นด้วยเครื่องหมาย “&”

อย่างไรก็ตาม เมื่อระบุพารามิเตอร์ใน AppMaster คุณไม่จำเป็นต้องคำนึงถึงกฎของคำขอ ทุกอย่างจะถูกจัดรูปแบบโดยอัตโนมัติ คุณเพียงแค่ต้องระบุชื่อของพารามิเตอร์เองและเพิ่มลงในรายการ

พารามิเตอร์การสืบค้นจะใช้เมื่อแหล่งข้อมูลเหมือนกัน แต่ตัวข้อมูลอาจแตกต่างกัน ตัวอย่างเช่น Boredapi มีรายการสิ่งที่ต้องทำมากมาย แต่เราสนใจเฉพาะรายการที่มีไว้สำหรับหนึ่งคนเท่านั้น และนั่นคือสิ่งที่เราระบุไว้ในพารามิเตอร์คำขอ

กรณีการใช้งานอื่นคือการจำกัดจำนวนข้อมูล ตัวอย่างเช่น เราสามารถเข้าถึงบางรายการได้ แต่ขอเพียง 5 รายการแรกเท่านั้น ปริมาณนี้ยังสามารถเป็นพารามิเตอร์การค้นหาได้อีกด้วย

อีกทางเลือกหนึ่งคือรหัสการเข้าถึง คุณอาจเคยใช้ตัวเลือกนี้ในโมดูลที่ 1 เมื่อกล่าวถึง Alphavantage สามารถรับข้อมูลได้หลังจากลงทะเบียนและส่งรหัสส่วนตัวในพารามิเตอร์คำขอเท่านั้น

ให้ความสนใจกับหน้าเว็บที่คุณเยี่ยมชมบนอินเทอร์เน็ต คุณอาจพบพารามิเตอร์ต่าง ๆ ในหน้าเหล่านั้นด้วย ตัวอย่างเช่น เปิดหน้าสภาพอากาศของ Ventusky.com ในพารามิเตอร์การค้นหา ค่าทางภูมิศาสตร์ของละติจูดและลองจิจูดจะถูกส่งไป

ส่วนหัว

ส่วนหัว ส่วนหัวของคำขอ ส่วนหัวมักจะมีข้อมูลบริการเกี่ยวกับคำขอ (ข้อมูลเมตา) ส่วนหัวอนุญาตให้เซิร์ฟเวอร์รับข้อมูลเพิ่มเติมเกี่ยวกับไคลเอนต์ที่ร้องขอข้อมูล ส่วนหัวสามารถมีข้อมูลเกี่ยวกับเบราว์เซอร์ที่กำลังใช้อยู่ การเข้ารหัสการตอบสนองที่คาดว่าจะเป็นภาษา ภาษาใด เวลาที่แน่นอนของคำขอ และอื่นๆ ในกรณีของการเข้าถึงข้อมูลที่ได้รับการป้องกัน ส่วนหัวอาจมีรหัสการให้สิทธิ์

ในกรณีส่วนใหญ่ ส่วนหัวเป็นตัวเลือก แม้แต่ในโมดูลแรก เราได้ส่งคำขอโดยที่เราไม่ได้ระบุส่วนหัวใด ๆ (แม้ว่าจะไม่ได้หมายความว่าคำขอนั้นถูกส่งจริง ๆ โดยไม่มีส่วนหัวก็ตาม)

ร่างกาย

ร่างกาย ขอเนื้อความ. คำขอ GET มักจะทำโดยไม่มีสิ่งนี้ แต่ถ้าเราต้องการส่งข้อมูลบางอย่างไปยังเซิร์ฟเวอร์ ให้ส่งคำขอ POST หรือ PUT จากนั้นข้อมูลนี้จะอยู่ในเนื้อหาคำขอ ในเวลาเดียวกัน คุณสามารถวางข้อมูลที่มีความซับซ้อนในเนื้อหาคำขอ เช่น ส่งไฟล์วิดีโอ และไม่จำกัดเพียงตัวเลขหรือสตริงข้อความ