วิธีสร้าง REST API: การออกแบบ ความปลอดภัย และการนำขึ้นใช้งานจริง

วิธีสร้าง REST API ให้เริ่มจากการเขียนรายการ resource ที่แอปของคุณจัดการ (ผู้ใช้ ออเดอร์ การจอง) ให้แต่ละรายการมี URL เช่น /orders และ /orders/{id} แล้วใช้ HTTP method สำหรับการทำงาน ได้แก่ GET เพื่ออ่าน, POST เพื่อสร้าง, PATCH เพื่อแก้ไข และ DELETE เพื่อลบ ส่งผลลัพธ์กลับเป็น JSON พร้อม status code ที่มีความหมาย ตรวจสอบข้อมูลขาเข้าทุกรายการ บังคับ การยืนยันตัวตน และตรวจสิทธิ์รายข้อมูลที่เซิร์ฟเวอร์ แบ่งหน้าของรายการด้วย pagination แล้วจึงเขียนเอกสารของ endpoint และนำ API ขึ้นใช้งานหลัง HTTPS

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

เมื่อไรที่คุณต้องใช้ REST API

• หน้าเว็บฝั่ง frontend ของคุณต้องบันทึกและโหลดข้อมูลจากเซิร์ฟเวอร์
• แอปมือถือ พาร์ตเนอร์ หรือเครื่องมืออัตโนมัติต้องเข้าถึงข้อมูลของคุณ
• บริการอื่นส่ง event มาให้คุณ (webhook)
• คุณแบ่งงานระหว่างทีม frontend และทีม backend

REST เป็นสไตล์ที่นิยมที่สุด แต่ไม่ใช่สไตล์เดียว REST กับ GraphQL อธิบายว่าเมื่อไรการใช้ endpoint สำหรับ query ที่ยืดหยุ่นเพียงจุดเดียวจะเหมาะกว่า

ออกแบบก่อน: resource และ route

เขียนคำนามทั้งหมดในแอปของคุณ และสิ่งที่ผู้ใช้ทำกับคำนามเหล่านั้น ตัวอย่างสำหรับแอปจองคิวอย่างง่าย:

เหล่านี้ตรงกับ create, read, update และ delete ดู CRUD คืออะไร แนวทางที่ควรทำตาม:

• ใช้คำนามพหูพจน์และไม่ใส่คำกริยาใน URL: /bookings ไม่ใช่ /getBookings
• ซ้อนได้เพียงชั้นเดียว เมื่อช่วยให้เห็นความเป็นเจ้าของ เช่น /bookings/{id}/notes
• การกระทำที่ไม่ใช่ CRUD สามารถเป็น sub-resource ได้ เช่น POST /bookings/{id}/cancel ชัดเจนกว่าการใช้ PATCH แบบซ่อนความหมาย
• ตั้งชื่อฟิลด์ให้สม่ำเสมอ เช่น ใช้ created_at ทุกที่

status code และข้อผิดพลาด

ใช้ HTTP code มาตรฐาน เพื่อให้ client รู้ผลลัพธ์โดยไม่ต้องแยกข้อความ:

ส่งข้อผิดพลาดกลับในโครงสร้าง JSON เดียวที่สม่ำเสมอ เช่น {"error": {"code": "slot_taken", "message": "เวลานั้นไม่ว่างแล้ว"}} และอย่าใส่ stack trace หรือข้อผิดพลาดของฐานข้อมูลลงในการตอบกลับเด็ดขาด

ตัวเลือกและการแลกเปลี่ยน

ทีละขั้นตอน

1. แสดงรายการ resource และ route ตามที่กล่าวข้างต้น รวมถึงระบุว่าใครเรียก route แต่ละตัวได้บ้าง
2. ออกแบบข้อมูล ในฐานข้อมูลด้วยฟิลด์และความสัมพันธ์ที่ต้องใช้
3. สร้าง route สำหรับการอ่านก่อน แล้วจึงสร้างการเพิ่ม การแก้ไข และการลบ
4. ตรวจสอบข้อมูลขาเข้า ทุกครั้งที่เขียนข้อมูล ด้วยไลบรารี schema: ฟิลด์ที่จำเป็น ชนิดข้อมูล ความยาว ค่าที่อนุญาต ปฏิเสธฟิลด์ที่ไม่รู้จัก
5. เพิ่มการยืนยันตัวตน แล้วตามด้วย การอนุญาตรายข้อมูล: การเปิดดู /bookings/42 ต้องตรวจว่าการจอง 42 เป็นของผู้เรียก ไม่ใช่แค่ตรวจว่ามีคนเข้าสู่ระบบอยู่
6. แบ่งหน้ารายการทุกรายการ และจำกัดขนาดหน้าสูงสุด
7. จำกัดอัตราการเรียก สำหรับการเข้าสู่ระบบและ route ที่ใช้ทรัพยากรมาก ดู rate limiting
8. ตั้งค่า CORS เฉพาะเมื่อเบราว์เซอร์จากโดเมนอื่นต้องเรียก API และระบุ origin เหล่านั้นอย่างชัดเจน วิธีแก้ข้อผิดพลาด CORS อธิบายข้อผิดพลาดที่คุณจะพบ
9. เขียนเอกสารและการทดสอบ สำหรับแต่ละ route รวมถึงกรณีที่ล้มเหลว
10. นำขึ้นใช้งาน โดยเก็บความลับในตัวแปรสภาพแวดล้อม ใช้ HTTPS มี log และ health check

พรอมต์สำหรับเครื่องมือสร้างแอปด้วย AI

สร้างโครง:

สร้าง REST API สำหรับการจอง โดยมี route ดังนี้ GET /api/health, GET /api/bookings (แบ่งหน้า สูงสุด 50 รายการต่อหน้า), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id เก็บข้อมูลในฐานข้อมูลของเรา ตรวจสอบเนื้อหาคำขอด้วยไลบรารี schema และปฏิเสธฟิลด์ที่ไม่รู้จัก ส่งข้อผิดพลาดเป็น JSON ในรูปแบบ {"error": {"code", "message"}} พร้อม status code ที่ถูกต้อง (400, 401, 403, 404, 409) เก็บความลับในตัวแปรสภาพแวดล้อม

ความปลอดภัย:

ให้ทุก route ของการจองต้องเข้าสู่ระบบก่อน ในทุกการอ่าน แก้ไข และลบ ให้ตรวจที่เซิร์ฟเวอร์ว่าการจองเป็นของผู้ใช้ปัจจุบัน ถ้าไม่ใช่ให้ส่ง 404 อย่ารับ user ID หรือ role จากเนื้อหาคำขอเด็ดขาด จำกัด POST /api/bookings ไว้ที่ 20 ครั้งต่อนาทีต่อผู้ใช้ บันทึกข้อผิดพลาดไว้ที่เซิร์ฟเวอร์ และอย่าส่ง stack trace กลับไปยังผู้ใช้

เอกสาร:

เขียนคำอธิบาย OpenAPI ของ route เหล่านี้ และ README สั้น ๆ ที่มีตัวอย่างคำขอและการตอบกลับของแต่ละ route

ทดสอบ API ของคุณ

ทดสอบจากภายนอก frontend เพราะผู้โจมตีก็จะทำเช่นนั้น:

• แต่ละ route ทำงานกับข้อมูลที่ถูกต้อง และส่งรูปแบบและ code ตามที่เอกสารระบุ
• ฟิลด์ที่ขาดหรือไม่ถูกต้องส่ง 400 พร้อมข้อความที่ชัดเจน
• ไม่มี token แล้วได้ 401 ในทุก route ที่ต้องยืนยันตัวตน
• ผู้ใช้ A ขอข้อมูลของผู้ใช้ B ด้วย ID แล้วได้ 404 หรือ 403
• รายการถูกแบ่งหน้า และค่า limit ที่สูงมากถูกจำกัด
• การสร้างข้อมูลซ้ำหรือขัดแย้งส่ง 409 ไม่ใช่ 500
• การเกินขีดจำกัดส่ง 429
• การตอบกลับข้อผิดพลาดไม่มี stack trace, SQL หรือความลับ
• CORS อนุญาตเฉพาะ origin ที่ตั้งใจไว้

ข้อผิดพลาดที่พบบ่อย

• ตรวจการเข้าสู่ระบบแต่ไม่ตรวจความเป็นเจ้าของ เป็นช่องโหว่ของ API ที่พบบ่อยที่สุด: ผู้ใช้ที่เข้าสู่ระบบคนไหนก็ได้สามารถอ่านข้อมูลของคนอื่นได้ด้วยการเปลี่ยน ID
• เชื่อ client มากเกินไป ราคา role และ user ID ในเนื้อหาคำขอสามารถถูกแก้ไขได้
• ส่งแถวทั้งหมดจากฐานข้อมูลกลับไป รหัสผ่านที่แฮชแล้วและฟิลด์ภายในจะรั่วไหล ให้เลือกว่าแต่ละการตอบกลับควรมีอะไรบ้าง
• รายการที่ไม่มีขอบเขต คำขอเดียวที่ดึงข้อมูลทุกรายการอาจทำให้ทั้งแอปช้าลง
• 200 OK พร้อมข้อความผิดพลาดอยู่ข้างใน client และระบบมอนิเตอร์จะไม่รู้ว่าล้มเหลว
• ตั้ง CORS ให้อนุญาตทุกอย่าง ใน API ที่ใช้ cookie
• ไม่มี health check หรือ log ทำให้คุณรู้ว่าระบบล่มจากผู้ใช้เท่านั้น

สำหรับการตรวจสอบก่อนเปิดตัวในภาพรวม ดู เช็กลิสต์ความปลอดภัยสำหรับแอปที่สร้างด้วย AI

สร้าง REST API ใน Mythex

คุณสามารถขอ API ใน Mythex ได้ ทั้งเป็นส่วนหนึ่งของแอปหรือเป็นบริการแยกต่างหาก เอกสารสูตร REST API backend มีพรอมต์เริ่มต้น: ระบุเฟรมเวิร์กและ route ของคุณ ขอข้อผิดพลาดแบบ JSON ที่ชัดเจน เก็บความลับในตัวแปรสภาพแวดล้อม และรวม Dockerfile ไว้ด้วย backend แบบ container ที่ใช้ Node, Python, C#, Java และภาษาอื่นจะเผยแพร่ผ่าน Dockerfile และ Mythex จัดการการนำขึ้นใช้งานจากเมนู Publish (API backend) โปรเจกต์หนึ่งสามารถรันเว็บไซต์และ API server คู่กันได้ และคุณสลับระหว่างสองอย่างในการพรีวิวได้ เก็บคีย์เป็น secret ของโปรเจกต์ และหาก API ต้องใช้ฐานข้อมูล ให้ขอในแชท สำหรับงานเบื้องหลังที่กำหนดเวลาซึ่งทำงานร่วมกับ API ของคุณ ดู วิธีรันงานเบื้องหลัง

คำถาม