RESTful API คืออะไร? มาออกแบบ API ให้โปรฯ

สวัสดีทุกคนครับ! ในโลกของการพัฒนาซอฟต์แวร์ เรามักจะได้ยินคำว่า "API" อยู่เสมอ โดยเฉพาะคำว่า "REST API" ที่เหมือนเป็นมาตรฐานของวงการไปแล้ว แต่เคยสงสัยไหมครับว่า อะไรที่ทำให้ API ธรรมดา ๆ กลายเป็น "RESTful API" ที่ดี?

วันนี้เราจะมาเจาะลึกสถาปัตยกรรมของ REST และเรียนรู้วิธีการออกแบบ API ให้ดูเป็นมืออาชีพและใช้งานง่ายกันครับ!

API คืออะไร? (ฉบับบริกรในร้านอาหาร 🧑‍🍳)

ก่อนอื่นเลย API (Application Programming Interface) ก็เปรียบเสมือน "บริกร" ในร้านอาหารครับ

คุณ (Frontend): คือลูกค้าที่นั่งอยู่ที่โต๊ะ
พ่อครัว (Backend/Database): คือคนที่ทำอาหารอยู่ในครัว
API (บริกร): คือคนกลางที่รับออเดอร์ (Request) จากคุณ ไปส่งให้พ่อครัว แล้วนำอาหาร (Response) ที่เสร็จแล้วกลับมาเสิร์ฟให้คุณที่โต๊ะ

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

แล้ว REST API ล่ะ?

REST (REpresentational State Transfer) ไม่ใช่เทคโนโลยีหรือภาษา แต่เป็น "สถาปัตยกรรม" หรือ "ชุดของกฎและแนวทาง" ในการออกแบบ API ให้ทำงานบนโปรโตคอล HTTP ได้อย่างมีประสิทธิภาพและเป็นมาตรฐานเดียวกัน

หัวใจหลักของ REST ประกอบด้วยแนวคิดง่าย ๆ ไม่กี่อย่างครับ:

ทรัพยากร (Resources): ทุกสิ่งทุกอย่างในระบบจะถูกมองเป็น "ทรัพยากร" เช่น users, products, orders ซึ่งแต่ละทรัพยากรจะมี URL ที่ไม่ซ้ำกันเป็นตัวระบุตัวตน (เช่น /users/123)
การกระทำ (Verbs/Methods): เราจะใช้ HTTP Methods (หรือ Verbs) ที่มีอยู่แล้วในการบอกว่าเราต้องการ "ทำอะไร" กับทรัพยากรนั้น ๆ
สถานะ (Representations): เมื่อเราขอข้อมูล Server จะส่ง "สถานะ" ของทรัพยากรนั้นกลับมา ซึ่งส่วนใหญ่อยู่ในรูปแบบของ JSON

การกระทำพื้นฐาน: CRUD และ HTTP Methods

การออกแบบ REST API ที่ดี จะใช้ HTTP Methods ให้ตรงกับความหมายของการกระทำ (CRUD) ดังนี้ครับ

การกระทำ (CRUD)	HTTP Method	ความหมาย	ตัวอย่างการใช้งาน
Create (สร้าง)	POST	สร้างทรัพยากรใหม่	POST /users (สร้าง user ใหม่)
Read (อ่าน)	GET	ขอข้อมูลทรัพยากร	GET /users (ดู user ทั้งหมด), GET /users/123 (ดู user ID 123)
Update (แก้ไข)	PUT / PATCH	อัปเดตข้อมูลทรัพยากร	PUT /users/123 (อัปเดตข้อมูล user ID 123 ทั้งหมด)
Delete (ลบ)	DELETE	ลบทรัพยากร	DELETE /users/123 (ลบ user ID 123)

เกร็ดความรู้: PUT ใช้สำหรับอัปเดตข้อมูล ทั้งก้อน (แทนที่ของเก่าทั้งหมด) ส่วน PATCH ใช้สำหรับอัปเดตแค่ บางส่วน ของข้อมูลนั่นเอง

เลื่อนขั้น! ทำให้ API ของเรา "RESTful" 👑

การใช้ HTTP Methods ถูกต้องเป็นแค่จุดเริ่มต้นครับ การจะทำให้ API ของเรา "RESTful" อย่างแท้จริงนั้น คือการปฏิบัติตามแนวทางเหล่านี้ เพื่อให้ API ของเรา คาดเดาได้ง่าย, เป็นมาตรฐาน, และ ใช้งานง่าย

1. ใช้คำนาม ไม่ใช่คำกริยา ใน URL

นี่คือกฎเหล็กข้อแรกเลยครับ! URL ควรจะระบุถึง "ทรัพยากร (คำนาม)" ไม่ใช่ "การกระทำ (คำกริยา)" เพราะเราใช้ HTTP Method เป็นตัวบอกการกระทำอยู่แล้ว

❌ ไม่ดี: GET /getAllUsers, POST /createNewUser
✅ ดีมาก: GET /users, POST /users

2. ใช้พหูพจน์สำหรับชื่อทรัพยากร

เพื่อให้เป็นมาตรฐานและเข้าใจตรงกัน เราควรใช้คำนามพหูพจน์ (Plural) สำหรับ Collection ของทรัพยากร

❌ ไม่ดี: /user/123, /product
✅ ดีมาก: /users/123, /products

3. ใช้ HTTP Status Codes เพื่อบอกผลลัพธ์

อย่าส่งแค่ 200 OK กลับไปทุกครั้ง! การใช้ Status Code ที่ถูกต้อง จะช่วยให้ฝั่ง Client รู้ทันทีว่าเกิดอะไรขึ้น

200 OK: สำเร็จ (สำหรับการ GET ทั่วไป)
201 Created: สร้างสำเร็จ (สำหรับการ POST)
204 No Content: สำเร็จ แต่ไม่มีข้อมูลส่งกลับ (สำหรับการ DELETE)
400 Bad Request: Request ที่ส่งมาไม่ถูกต้อง (เช่น ข้อมูลขาดหายไป)
401 Unauthorized: ไม่ได้ยืนยันตัวตน (ยังไม่ได้ Login)
403 Forbidden: ยืนยันตัวตนแล้ว แต่ไม่มีสิทธิ์เข้าถึงทรัพยากรนี้
404 Not Found: ไม่พบทรัพยากรที่ร้องขอ
500 Internal Server Error: เกิดข้อผิดพลาดขึ้นที่ฝั่ง Server

4. การจัดการความสัมพันธ์ (Nested Resources)

สำหรับทรัพยากรที่มีความสัมพันธ์กัน เราสามารถออกแบบ URL ให้ซ้อนกันได้เพื่อสื่อความหมายที่ชัดเจน

ตัวอย่าง: หากต้องการดู "ความคิดเห็น (comments)" ทั้งหมดของ "บทความ (post)" ที่มี ID เป็น 123
✅ URL ที่ดี: GET /posts/123/comments

5. การทำ Versioning

เมื่อ API ของเรามีการเปลี่ยนแปลงครั้งใหญ่ที่ไม่สามารถเข้ากันได้กับเวอร์ชันเก่า (Breaking Change) การทำ Versioning เป็นสิ่งจำเป็น เพื่อไม่ให้กระทบกับผู้ใช้เก่า

วิธีที่นิยม: ใส่เวอร์ชันไว้ใน URL เช่น /v1/users, /v2/users

ตัวอย่างการออกแบบ RESTful API สำหรับระบบ Blog

ลองนำทุกอย่างมารวมกันในการออกแบบ API สำหรับระบบ Blog ง่าย ๆ ครับ

GET /posts: ดึงบทความทั้งหมด
GET /posts/45: ดึงบทความ ID 45
POST /posts: สร้างบทความใหม่
PUT /posts/45: อัปเดตบทความ ID 45
DELETE /posts/45: ลบบทความ ID 45
GET /posts/45/comments: ดึงความคิดเห็นทั้งหมดของบทความ ID 45
POST /posts/45/comments: เพิ่มความคิดเห็นใหม่ในบทความ ID 45

เห็นไหมครับว่ามัน อ่านง่าย, คาดเดาได้, และ เป็นระบบระเบียบ มากแค่ไหน?

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