เริ่มสร้าง REST API ด้วย Express โดยคิดจาก Resource ก่อน

เวลาหัดทำ REST API ด้วย Express หลายคนมักเริ่มจากคำถามว่า route ควรชื่ออะไรดี แต่จริง ๆ แล้วจุดเริ่มที่แข็งแรงกว่าคือการมองระบบของเราเป็น resource ก่อน ว่าระบบนี้มีข้อมูลหลักอะไรบ้าง เช่น users, products หรือ orders

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

เริ่มจากการหา Resource ของระบบ

resource คือหน่วยข้อมูลหลักที่ API ต้องดูแล เช่น

• users
• products
• orders

เมื่อเราเลือก resource ได้แล้ว การออกแบบ route ก็จะเป็นธรรมชาติมากขึ้น ตัวอย่างเช่น ถ้ามี resource ชื่อ users:

• GET /users ใช้ดูรายการผู้ใช้
• GET /users/:id ใช้ดูผู้ใช้รายคน
• POST /users ใช้สร้างผู้ใช้ใหม่
• PATCH /users/:id ใช้แก้ไขข้อมูลบางส่วน
• DELETE /users/:id ใช้ลบผู้ใช้

รูปแบบนี้คือหัวใจสำคัญของ REST API ที่ทำให้คนในทีมอ่านแล้วเข้าใจตรงกันได้ง่าย

Express ทำให้การ Map Route กับ Handler อ่านง่าย

ข้อดีของ Express คือสามารถเขียนการจับคู่ระหว่าง HTTP method กับ route ได้ตรงไปตรงมา เช่น

app.get("/users", listUsers)
app.post("/users", createUser)
app.patch("/users/:id", updateUser)

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

มือใหม่ควรเริ่มจาก In-Memory ก่อน

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

เหตุผลคือเป้าหมายแรกของการเรียนทำ API ไม่ใช่การจัดการ database แต่คือการเข้าใจเรื่องสำคัญเหล่านี้:

• request เข้ามาอย่างไร
• response ควรส่งกลับแบบไหน
• status code แต่ละแบบใช้เมื่อไร

เมื่อเข้าใจพื้นฐานเหล่านี้ดีแล้ว ค่อยต่อยอดไปสู่ database, validation หรือระบบ auth จะง่ายกว่าและเห็นภาพมากกว่า

Status Code สำคัญกว่าที่หลายคนคิด

REST API ที่ดีไม่ได้มีแค่ route ที่ตั้งชื่อสวย แต่ต้องสื่อสารผลลัพธ์ผ่าน status code อย่างถูกต้องด้วย ตัวอย่างที่ควรรู้มีดังนี้

• 200 สำเร็จทั่วไป
• 201 สร้างข้อมูลสำเร็จ
• 400 ข้อมูล input ไม่ถูกต้อง
• 404 ไม่พบข้อมูลที่ต้องการ
• 500 เกิดข้อผิดพลาดจากฝั่ง server

การใช้ status code ให้เหมาะสมจะช่วยให้ทั้ง frontend, backend และคนที่มาใช้งาน API เข้าใจตรงกันว่าผลลัพธ์ที่เกิดขึ้นคืออะไร

Response ควรมีรูปแบบที่เดาได้

อีกเรื่องที่สำคัญไม่แพ้กันคือความสม่ำเสมอของ response ถ้า API บาง route ส่งกลับเป็น string แต่บาง route ส่งเป็น object โดยไม่มีรูปแบบตายตัว คนที่ใช้งาน API จะสับสนทันที

แนวทางที่ดีคือ:

• ถ้าสำเร็จ ควรส่ง data
• ถ้าเกิดข้อผิดพลาด ควรส่ง error message ที่อ่านเข้าใจได้

ตัวอย่าง error response ที่ชัดเจน:

res.status(400).json({
  error: "name is required"
})

รูปแบบนี้ทำให้ผู้ใช้ API รู้ได้ทันทีว่าปัญหาคืออะไร และควรแก้อย่างไรต่อ

REST ไม่จำเป็นต้องเป๊ะทุกทฤษฎีตั้งแต่วันแรก

หลายคนกังวลว่าถ้าจะทำ REST API ต้องทำให้ตรงตามทฤษฎีทุกข้อทันที แต่ในทางปฏิบัติ สิ่งสำคัญกว่าคือการมีรูปแบบที่ทีมอ่านแล้วเข้าใจตรงกัน

ประเด็นที่ควรทำให้สม่ำเสมอได้แก่:

• การตั้งชื่อ route
• การเลือกใช้ HTTP method
• การส่ง status code
• รูปแบบของ response

ต่อให้ยังไม่สมบูรณ์แบบตามหลักทั้งหมด แต่ถ้าทีมใช้งานได้ตรงกัน โค้ดก็จะดูแลง่ายและพัฒนาได้เร็วกว่า

เมื่อ API เริ่มใหญ่ ควรแยกไฟล์ Route

ถ้าโปรเจกต์เริ่มมีหลาย resource การรวมทุกอย่างไว้ในไฟล์เดียวจะทำให้โค้ดรกและอ่านยาก ทางออกที่ดีคือแยก route ตาม resource เช่น

• users.routes.js
• products.routes.js
• orders.routes.js

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

เริ่มจาก CRUD เล็ก ๆ ให้ครบก่อน

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

• Create
• Read
• Update
• Delete

เมื่อทำได้ครบแล้ว ค่อยเพิ่มความสามารถอื่นทีละชั้น เช่น

• validation
• database
• authentication
• logging

การไล่เป็นขั้นแบบนี้จะช่วยให้เห็นภาพชัดว่า Express ทำหน้าที่เป็นโครงกระดูกของ API อย่างไร และทำให้เราเข้าใจพื้นฐานได้แน่นก่อนขยับไปเรื่องที่ซับซ้อนกว่า

สรุป

การเริ่มสร้าง REST API ด้วย Express ที่ดี ควรเริ่มจากการมองระบบเป็น resource ก่อน ไม่ใช่เริ่มจากการตั้งชื่อ route อย่างเดียว เพราะแนวคิดนี้ช่วยให้การออกแบบ endpoint เป็นธรรมชาติ เข้าใจง่าย และสื่อสารกันในทีมได้ตรงกัน

สำหรับผู้เริ่มต้น ควรฝึกจาก CRUD ง่าย ๆ ใช้ข้อมูลใน memory ไปก่อน แล้วให้ความสำคัญกับ request, response และ status code เมื่อพื้นฐานแน่นแล้วจึงค่อยเพิ่ม validation, database, auth และส่วนประกอบอื่น ๆ ตามลำดับ วิธีนี้จะทำให้เห็นภาพของ Express ในฐานะโครงสร้างหลักของ API ได้ชัดเจนและนำไปต่อยอดได้จริง