REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples ดาวน์โหลด - REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples ซอร์สโค้ดดาวน์โหลด

REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples

หมวดหมู่อื่นๆ

1.0.0

ดาวน์โหลด

REST API แบบฝึกหัด: สร้าง REST API และบริการสีขาว, วิธีที่ถูกต้องในการพัฒนา API, REST API ตัวอย่าง

สร้าง REST API โดยใช้เทคโนโลยีแนวโน้ม

สร้าง REST API ด้วยเทคโนโลยีที่ได้รับความนิยมมากที่สุด - PHP, Python, GO, NodeJS และกรอบที่ได้รับความนิยมมากที่สุด - Django, Laravel, Lumen, Gin

REST API หรือ RESTFUL API คืออะไร?

ส่วนที่เหลือเป็นตัวย่อสำหรับการถ่ายโอนสถานะการเป็นตัวแทน Restful API เป็นรูปแบบสถาปัตยกรรมสำหรับ อินเตอร์เฟสโปรแกรมแอปพลิเคชัน (API) ที่ใช้ คำขอ HTTP เพื่อเข้าถึงและแก้ไขข้อมูล ข้อมูลนั้นสามารถใช้เพื่อ รับวางโพสต์และลบ ประเภทข้อมูลซึ่งหมายถึง การอ่านอัปเดตการสร้างและการลบ การดำเนินงานที่เกี่ยวข้องกับทรัพยากร สำหรับรายละเอียดเพิ่มเติม

ฟังก์ชั่นหลักที่ใช้ในสถาปัตยกรรมส่วนที่เหลือคือ:

รับ -ให้การเข้าถึงทรัพยากรแบบอ่านอย่างเดียว
ใส่ - สร้างทรัพยากรใหม่
ลบ - ลบทรัพยากร
โพสต์ - อัปเดตทรัพยากรที่มีอยู่หรือสร้างทรัพยากรใหม่

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

หลักการพักผ่อน

มีหลักการภาคพื้นดินหกประการด้านล่างเป็นหลักการที่เหลือหกหลักการของการพักผ่อน:

ไร้สัญชาติ: คำขอที่ส่งจากไคลเอนต์ไปยังเซิร์ฟเวอร์มีข้อมูลที่จำเป็นทั้งหมดที่จำเป็นต้องเข้าใจอย่างสมบูรณ์ มันสามารถเป็นส่วนหนึ่งของ URI, พารามิเตอร์การสืบค้น, ร่างกายหรือแม้แต่ส่วนหัว URI ใช้สำหรับการระบุทรัพยากรที่ไม่ซ้ำกันและร่างกายมีสถานะของทรัพยากรที่ร้องขอ เมื่อการประมวลผลเสร็จสิ้นโดยเซิร์ฟเวอร์การตอบกลับที่เหมาะสมจะถูกส่งกลับไปยังไคลเอนต์ผ่านส่วนหัวสถานะหรือการตอบสนอง
Client-Server: มีอินเทอร์เฟซแบบสม่ำเสมอที่แยกไคลเอนต์ออกจากเซิร์ฟเวอร์ การแยกข้อกังวลช่วยในการปรับปรุงความสามารถในการพกพาของผู้ใช้ในหลายแพลตฟอร์มรวมถึงเพิ่มความสามารถในการปรับขนาดของส่วนประกอบเซิร์ฟเวอร์
อินเทอร์เฟซแบบสม่ำเสมอ: เพื่อให้ได้ความสม่ำเสมอตลอดทั้งแอปพลิเคชัน REST ได้กำหนดข้อ จำกัด อินเตอร์เฟสสี่ข้อซึ่ง ได้แก่ :
```
  Resource identification
  Resource Manipulation using representations
  Self-descriptive messages
  Hypermedia as the engine of application state
```
Cacheable: เพื่อให้ได้ประสิทธิภาพที่ดีขึ้นแอปพลิเคชันมักจะทำให้แคชได้ มันทำได้โดยการติดฉลากการตอบสนองจากเซิร์ฟเวอร์ว่าแคชหรือไม่สามารถแคชได้ทั้งโดยปริยายหรือโดยชัดแจ้ง หากการตอบสนองถูกกำหนดเป็นแคชได้แคชไคลเอนต์สามารถนำข้อมูลการตอบกลับมาใช้ใหม่สำหรับการตอบสนองที่เทียบเท่าในอนาคต นอกจากนี้ยังช่วยในการป้องกันการใช้ข้อมูลซ้ำซากซ้ำ
ระบบเลเยอร์: สถาปัตยกรรมระบบเลเยอร์ช่วยให้แอปพลิเคชันมีความเสถียรมากขึ้นโดยการ จำกัด พฤติกรรมส่วนประกอบ สถาปัตยกรรมนี้ช่วยให้สามารถโหลดบาลานซ์และให้แคชที่ใช้ร่วมกันเพื่อส่งเสริมความสามารถในการปรับขนาด สถาปัตยกรรมแบบเลเยอร์ยังช่วยในการเพิ่มความปลอดภัยของแอปพลิเคชันเนื่องจากส่วนประกอบในแต่ละเลเยอร์ไม่สามารถโต้ตอบได้นอกเหนือจากเลเยอร์ทันทีถัดไป
Code on Demand: Code on Demand เป็นข้อ จำกัด ทางเลือกและใช้น้อยที่สุด อนุญาตให้ดาวน์โหลดรหัสหรือแอปเพล็ตไคลเอนต์ผ่านอินเตอร์เฟสที่จะใช้ภายในแอปพลิเคชัน ในสาระสำคัญมันทำให้ลูกค้าง่ายขึ้นโดยการสร้างแอปพลิเคชันอัจฉริยะซึ่งไม่พึ่งพาโครงสร้างรหัสของตัวเอง

ตอนนี้คุณรู้ว่า API REST คืออะไรและสิ่งที่คุณต้องคำนึงถึงเพื่อส่งมอบแอปพลิเคชันที่มีประสิทธิภาพให้ดำน้ำลึกลงไปและดูกระบวนการสร้าง API REST โดยใช้เทคโนโลยีที่ได้รับความนิยมและ FrameWrks ทั้งหมด

REST API แตกต่างจากสบู่อย่างไร?

REST และ Simple Object Access Protocol (SOAP) เสนอวิธีการที่แตกต่างกันในการเรียกใช้บริการเว็บ REST เป็นสไตล์สถาปัตยกรรมในขณะที่ SOAP กำหนดข้อกำหนดการสื่อสารมาตรฐานสำหรับการแลกเปลี่ยนข้อความที่ใช้ XML แอปพลิเคชันที่เหลือสามารถใช้สบู่

บริการบนเว็บที่ไม่มีที่อยู่อาศัยไม่มีสัญชาติ การใช้งานตามส่วนที่เหลือนั้นง่ายเมื่อเทียบกับสบู่ แต่ผู้ใช้จะต้องเข้าใจบริบทและเนื้อหาที่ถูกส่งผ่านเนื่องจากไม่มีชุดกฎมาตรฐานเพื่ออธิบายอินเทอร์เฟซบริการเว็บที่เหลือ บริการ REST มีประโยชน์สำหรับอุปกรณ์โปรไฟล์ที่ จำกัด เช่นมือถือและง่ายต่อการรวมเข้ากับเว็บไซต์ที่มีอยู่

SOAP ต้องใช้รหัสประปาน้อยลงซึ่งหมายถึงรหัสโครงสร้างพื้นฐานระดับต่ำที่เชื่อมต่อโมดูลรหัสหลักเข้าด้วยกันมากกว่าการออกแบบบริการ REST ภาษาคำอธิบายบริการเว็บอธิบายชุดกฎทั่วไปเพื่อกำหนดข้อความการผูกการดำเนินการและที่ตั้งของบริการ SOAP Web Services มีประโยชน์สำหรับการประมวลผลแบบอะซิงโครนัสและการเรียกร้อง

วิธีการสร้าง REST API ที่มีประสิทธิภาพสูง และแนวปฏิบัติที่ดีที่สุด

นี่คือบางจุดที่คุณต้องพิจารณาเมื่อพัฒนา REST API:

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

1- ลดและ จำกัด ขนาดน้ำหนักบรรทุก

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

เราสามารถใช้ GZip Compression เพื่อลดขนาดน้ำหนักบรรทุกของเรา สิ่งนี้จะช่วยลดขนาดการดาวน์โหลดของการตอบสนองของเราบนเว็บแอป (ฝั่งไคลเอ็นต์) รวมถึงเพิ่มความเร็วในการอัปโหลดหรือการสร้างเอนทิตีบางส่วน (คำสั่งซื้อ) เราสามารถใช้ Deflate compression บนเว็บ API หรือเราสามารถอัปเดตส่วนหัวที่ยอมรับได้

2- เปิดใช้งานการแคช

การแคชเป็นหนึ่งในวิธีที่ง่ายที่สุดในการปรับปรุงประสิทธิภาพของ API หากเรามีการร้องขอที่ให้คำตอบที่เหมือนกันบ่อยครั้งการตอบสนองที่แคชนั้นจะช่วย หลีกเลี่ยงการสืบค้นการโทร/ฐานข้อมูลเพิ่มเติมคุณ จะต้องแน่ใจว่าเมื่อใช้การแคชเพื่อทำให้ข้อมูลในแคชเป็นระยะโดยเฉพาะอย่างยิ่งเมื่อมีการอัปเดตข้อมูลใหม่

แต่มันอาจทำให้คุณสับสนเมื่อใดหรือที่ไหนที่จะใช้แคช?

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

3- ให้ความเร็วเครือข่ายที่เพียงพอ

เครือข่ายที่ช้าจะลดประสิทธิภาพของ API ที่ออกแบบมาอย่างดีที่สุด เครือข่ายที่ไม่น่าเชื่อถืออาจทำให้เกิดการหยุดทำงานซึ่งอาจทำให้องค์กรของคุณละเมิด SLA ข้อกำหนดในการให้บริการและสัญญาที่คุณอาจทำกับลูกค้าของคุณ เป็นสิ่งสำคัญที่จะต้องลงทุนในโครงสร้างพื้นฐานเครือข่ายที่เหมาะสมเพื่อให้เราสามารถรักษาระดับประสิทธิภาพที่ต้องการได้ สิ่งนี้สามารถทำได้โดยการใช้ประโยชน์จากการซื้อทรัพยากรคลาวด์และโครงสร้างพื้นฐานที่เพียงพอ (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) นอกจากนี้หากคุณมีกระบวนการพื้นหลังจำนวนมากให้เรียกใช้ในเธรดแยกต่างหากเพื่อหลีกเลี่ยงการปิดกั้นคำขอ นอกจากนี้คุณยังสามารถใช้กระจกและเครือข่ายการส่งเนื้อหา (CDNs) เช่น CloudFront เพื่อให้บริการคำขอได้เร็วขึ้นในส่วนต่าง ๆ ของโลก

4- ป้องกันการโทรโดยไม่ตั้งใจการชะลอตัวและการละเมิด

คุณสามารถมีสถานการณ์ที่ API ของคุณทนทุกข์ทรมานจากการโจมตี DDOS ที่อาจเป็นอันตรายและตั้งใจหรือไม่ได้รับรู้เมื่อวิศวกรเรียก API ให้ดำเนินการลูปจากแอปพลิเคชันท้องถิ่นบางตัว คุณสามารถหลีกเลี่ยงสิ่งนี้ได้โดยการวัดธุรกรรมและ monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API)

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

5- พยายามใช้แพทช์มากกว่าใส่

มันเป็นความเข้าใจผิดที่พบบ่อยในหมู่วิศวกรที่ใส่และแพตช์การดำเนินงานให้ผลลัพธ์เดียวกันพวกเขามีความคล้ายคลึงกันในการอัปเดตทรัพยากร แต่พวกเขาแต่ละคนทำการอัปเดตแตกต่างกัน ใส่ทรัพยากรอัปเดตการดำเนินงานโดยส่งการอัปเดตไปยังทรัพยากรทั้งหมด การดำเนินการแพตช์ใช้การอัปเดตบางส่วนกับทรัพยากรที่ต้องการการอัปเดตเท่านั้น ผลลัพธ์ที่เกิดจากการโทร Inpatch ที่ให้น้ำหนักบรรทุกที่เล็กลงและปรับปรุงประสิทธิภาพในระดับ

   Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent. 
    Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls. 
    So, you should carefully and deliberately consider your application for using PATCH requests, 
    and make sure that they are idempotently implemented if needed. If not, use PUT requests.

6- เปิดใช้งานการบันทึกการตรวจสอบและการแจ้งเตือน

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

มีบันทึกการตรวจสอบและแจ้งเตือนวิศวกรช่วยวินิจฉัยและแก้ไขปัญหาก่อนที่จะกลายเป็นปัญหา APIs จำนวนมาก (Express/Node-based, Java, GO) มีจุดสิ้นสุดที่กำหนดไว้ล่วงหน้าสำหรับการประเมินสิ่งต่าง ๆ เช่น:

 `/health`
`/metrics`

หากคุณไม่ได้เปิดใช้งานการบันทึกและมีปัญหาที่อาจเกิดขึ้นคุณจะไม่สามารถติดตามต้นกำเนิดหรือปัญหาที่เกิดขึ้นในคำขอเฉพาะ

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

และ…หากคุณไม่ได้เปิดใช้งานการแจ้งเตือนคุณจะไม่ทราบว่ามีปัญหาหรือไม่จนกว่าลูกค้า (หรือแย่กว่านั้นคือลูกค้า) รายงาน

7- เปิดใช้งานการปนเปื้อน

การปนเปื้อนช่วยสร้างถังเนื้อหาจากการตอบสนองหลายครั้ง การเพิ่มประสิทธิภาพประเภทนี้ช่วยปรับปรุงการตอบสนองในขณะที่รักษาข้อมูลที่ถ่ายโอน/แสดงต่อลูกค้า คุณสามารถสร้างมาตรฐานแบ่งส่วนและ จำกัด การตอบสนองที่ช่วยลดความซับซ้อนของผลลัพธ์และปรับปรุงประสบการณ์ของลูกค้าโดยรวมโดยให้การตอบสนอง/ผลลัพธ์สำหรับสิ่งที่ลูกค้าขอเท่านั้น

บทสรุป

เรารู้ว่า APIs นั้นยอดเยี่ยมและสามารถมีพลังอย่างมากในการมอบประสบการณ์ที่ยอดเยี่ยมให้กับธุรกิจและลูกค้าหากได้รับการปรับปรุงและปรับปรุงประสิทธิภาพอย่างเหมาะสม ข้อกำหนดทางธุรกิจและความคาดหวังของลูกค้าจะพัฒนาขึ้นตลอดเวลา และในฐานะวิศวกรที่รับผิดชอบมันขึ้นอยู่กับเราในการตัดสินใจว่าจะสร้าง APIs ของเราในลักษณะที่สามารถช่วยให้เราบรรลุเป้าหมายได้และเกินเป้าหมายของเรา

เคล็ดลับเหล่านี้เป็นเพียงส่วนเล็ก ๆ ของภูเขาน้ำแข็งและนำไปใช้กับ API ทั้งหมดในการตั้งค่าทั่วไป ขึ้นอยู่กับ API และกรณีการใช้งานของคุณโดยเฉพาะบริการใดที่มีการโต้ตอบกับความถี่ที่ได้รับการเรียกจากที่ที่ได้รับการเรียก ฯลฯ คุณอาจต้องใช้เคล็ดลับเหล่านี้ในรูปแบบที่แตกต่างกัน