Wrikka Learn

Dark mode

RESTful API: สิ่งที่ต้องรู้ ​

หลักการพื้นฐาน ​

  • REST (Representational State Transfer) คือรูปแบบการออกแบบ API ที่ยึดตามหลักการของ HTTP protocol
  • ใช้ HTTP methods เพื่อกำหนดการกระทำต่อข้อมูล (GET, POST, PUT, DELETE)
  • กำหนด URL เพื่อระบุทรัพยากร (Resources) ที่ต้องการจัดการ เช่น /users, /products
  • ทำงานแบบไม่เก็บสถานะ (Stateless) โดยทุก request จะมีข้อมูลที่จำเป็นครบถ้วนในตัวเอง

แผนภาพแสดงการทำงานของ REST API:

HTTP Methods ​

  • GET: ใช้สำหรับดึงข้อมูล (Read)
    GET /api/users
GET /api/users/123
  • POST: ใช้สำหรับสร้างข้อมูลใหม่ (Create)
    POST /api/users
Body: { "name": "John", "email": "[email protected]" }
  • PUT/PATCH: ใช้สำหรับอัพเดทข้อมูล (Update)
    • PUT: อัพเดทข้อมูลทั้งหมดของทรัพยากร
    • PATCH: อัพเดทเฉพาะบางส่วนของทรัพยากร
    PUT /api/users/123
Body: { "name": "John", "email": "[email protected]" }

PATCH /api/users/123
Body: { "email": "[email protected]" }
  • DELETE: ใช้สำหรับลบข้อมูล (Delete)
    DELETE /api/users/123

Status Codes ​

  • 2xx: การทำงานสำเร็จ (Success)
    • 200 OK: คำขอสำเร็จเรียบร้อย
      HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "John Doe",
  "email": "[email protected]"
}
    • 201 Created: สร้างข้อมูลใหม่สำเร็จ
      HTTP/1.1 201 Created
Location: /api/users/123
Content-Type: application/json

{
  "id": 123,
  "name": "John Doe",
  "email": "[email protected]"
}
    • 204 No Content: การทำงานสำเร็จแต่ไม่มีข้อมูลส่งกลับ (มักใช้กับ DELETE)
      HTTP/1.1 204 No Content
  • 4xx: ข้อผิดพลาดจากฝั่งผู้ใช้ (Client Error)
    • 400 Bad Request: รูปแบบคำขอไม่ถูกต้อง
      HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Invalid email format"
}
    • 401 Unauthorized: ยังไม่ได้ยืนยันตัวตน (ต้องการการ authenticate)
      HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

{
  "error": "Authentication required"
}
    • 403 Forbidden: ไม่มีสิทธิ์เข้าถึงทรัพยากร (ยืนยันตัวตนแล้วแต่ไม่มีสิทธิ์)
      HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "You don't have permission to access this resource"
}
    • 404 Not Found: ไม่พบทรัพยากรที่ร้องขอ
      HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "User with ID 123 not found"
}
  • 5xx: ข้อผิดพลาดจากฝั่งเซิร์ฟเวอร์ (Server Error)
    • 500 Internal Server Error: เกิดข้อผิดพลาดภายในเซิร์ฟเวอร์
      HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "An unexpected error occurred"
}

รูปแบบข้อมูล ​

  • JSON เป็นรูปแบบที่นิยมใช้มากที่สุดในการรับส่งข้อมูล

ตัวอย่าง JSON response:

json
{
  "id": 123,
  "name": "John Doe",
  "email": "[email protected]",
  "roles": ["user", "admin"],
  "created_at": "2023-01-15T08:30:00Z"
}
  • ควรระบุ Content-Type header เพื่อบอกรูปแบบข้อมูล (เช่น Content-Type: application/json)

การยืนยันตัวตน (Authentication) ​

  • Basic Auth: ส่งชื่อผู้ใช้และรหัสผ่านในรูปแบบ Base64
    Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
  • API Keys: ใช้คีย์เฉพาะในการระบุตัวตนของแอปพลิเคชัน
    Authorization: ApiKey abc123xyz456
  • JWT (JSON Web Tokens): ใช้โทเค็นที่มีการเข้ารหัสและลงลายมือชื่อดิจิทัล
    Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
  • OAuth: มาตรฐานการยืนยันตัวตนที่ช่วยให้แอปพลิเคชันเข้าถึงข้อมูลได้โดยผู้ใช้ไม่ต้องเปิดเผยรหัสผ่าน

แนวทางปฏิบัติที่ดี (Best Practices) ​

  • กำหนดเวอร์ชันให้ API: เช่น /api/v1/users เพื่อรองรับการเปลี่ยนแปลงในอนาคต
  • ออกแบบ Endpoints ด้วยคำนาม ไม่ใช่คำกริยา:
    • ✅ ดี: /users
    • ❌ ไม่ดี: /getUsers
  • จัดการข้อมูลจำนวนมากด้วยการแบ่งหน้า (Pagination):
    GET /api/users?page=2&limit=10
  • ใช้ HTTPS เสมอ เพื่อรักษาความปลอดภัยในการส่งข้อมูล
  • จัดทำเอกสารประกอบ API อย่างละเอียด ด้วยเครื่องมือเช่น Swagger หรือ OpenAPI

โครงสร้างการออกแบบ RESTful API: