API คืออะไร — ทำไมถึงอยู่ในทุกแอปที่คุณใช้

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

ทั้งหมดนั้น developer ไม่ได้เขียนระบบธนาคารเอง และธนาคารก็ไม่ได้รู้อะไรเกี่ยวกับแอปนั้นด้วย แต่ทั้งสองฝั่งสามารถทำงานร่วมกันได้ เพราะมีสิ่งที่เรียกว่า API

🤔 API คืออะไรกันแน่#

API ย่อมาจาก Application Programming Interface — ฟังดูซับซ้อน แต่จริง ๆ แล้วคือ “ช่องทางที่กำหนดไว้สำหรับให้สองระบบคุยกัน”

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

API ทำหน้าที่เสมือน สัญญา (contract) ระหว่างสองฝั่ง ฝั่งที่ให้บริการจะประกาศว่าตัวเองมี endpoint อะไรบ้าง รับข้อมูลแบบไหน และจะตอบกลับมาในรูปแบบอะไร - ในขณะที่ฝั่งที่ใช้งานก็แค่ทำตามสัญญานั้น โดยไม่ต้องรู้เลยว่าข้างในทำงานยังไง

💡 ทำไม API ถึงสำคัญ#

ก่อนที่ API จะแพร่หลาย ถ้าต้องการให้แอปสองตัวคุยกัน บางทีต้องส่งไฟล์ Excel ให้กันผ่านระบบ หรือเชื่อมฐานข้อมูลโดยตรง ซึ่งอันตรายและจัดการยากมาก

API แก้ปัญหานี้ด้วยการเป็น ชั้นกลาง ที่ควบคุมได้ เปิดเฉพาะสิ่งที่ต้องการให้เห็น ซ่อนทุกอย่างที่ไม่ควรเปิดเผย และกำหนดได้ว่าใครจะเรียกใช้ได้บ้าง

ตัวอย่างในชีวิตจริงที่เราเจอทุกวัน:

• แอปดูดวงที่ดึงพยากรณ์อากาศจาก weather API
• เว็บ e-commerce ที่จ่ายเงินผ่าน Omise หรือ Stripe
• แชทบอทที่ส่งคำถามไปให้ Claude หรือ GPT ตอบ

ทุกอย่างเชื่อมกันผ่าน API ทั้งนั้น

🌐 REST คืออะไร และทำไมถึงพูดถึงกันบ่อย#

พอเข้าใจว่า API ทำอะไร คำถามถัดมาคือ — แล้วในทางปฏิบัติ API มีรูปแบบไหนบ้าง?

API มีหลายรูปแบบ แต่ที่ได้ยินบ่อยที่สุดในงาน web คือ REST (Representational State Transfer)

REST ไม่ใช่ protocol ไม่ใช่ framework แต่เป็น สไตล์การออกแบบ ที่ทำงานบน HTTP protocol

แนวคิดหลักคือ REST มองทุกอย่างเป็น “resource” และเราใช้ HTTP method ที่คุ้นเคยอยู่แล้วในการจัดการ resource เหล่านั้น

ทำให้ URL ที่เรียกใช้มีแบบแผนชัดเจน เช่น:

GET  /products          → ดูสินค้าทั้งหมด
GET  /products/42       → ดูสินค้าชิ้นที่ 42
POST /products          → เพิ่มสินค้าใหม่
DELETE /products/42     → ลบสินค้าชิ้นที่ 42

แค่อ่าน URL ก็รู้แล้วว่า API นั้นทำอะไร

👀 ดู REST API ในชีวิตจริงกัน#

สมมติเราเปิดเว็บ e-commerce แล้วหน้า product list ต้องโหลดสินค้า browser จะส่ง request แบบนี้:

GET https://api.myshop.com/products?category=shoes&limit=20

server รับแล้วตอบกลับมาเป็น JSON:

{
  "data": [
    {
      "id": 1,
      "name": "Nike Air Max",
      "price": 3500,
      "stock": 12
    },
    {
      "id": 2,
      "name": "Adidas Ultraboost",
      "price": 4200,
      "stock": 5
    }
  ],
  "total": 48,
  "page": 1
}

frontend รับ JSON นี้ไปแล้วก็ render หน้าเว็บออกมา

✅ ข้อดีของ REST#

เรียบง่ายและเรียนรู้ได้เร็ว เพราะต่อยอดจาก HTTP ที่นักพัฒนาส่วนใหญ่รู้จักอยู่แล้ว ไม่ต้องเรียนอะไรใหม่จากศูนย์

เครื่องมือรองรับเยอะมาก ทั้ง Postman, curl, browser developer tools ล้วนทำงานกับ REST ได้เลย debugging ง่าย

ยืดหยุ่น ไม่บังคับว่า server ต้องเขียนด้วยภาษาอะไร client ก็เช่นกัน ขอแค่รองรับ HTTP และ JSON ก็สามารถคุยกันได้เลย

Stateless (ไม่เก็บสถานะ) แต่ละ request พกข้อมูลที่ต้องการมาครบในตัวเอง server ไม่ต้องจำ session ของ client ทำให้ scale ออกได้ง่าย

⚠️ ข้อจำกัดที่ควรรู้#

REST ไม่ได้สมบูรณ์แบบในทุกกรณี มีบางจุดที่ควรระวัง เช่น:

Over-fetching และ Under-fetching — บางครั้ง endpoint คืนข้อมูลมามากเกินกว่าที่ต้องการ (over-fetching) หรือต้องเรียกหลาย endpoint เพื่อประกอบข้อมูลชุดเดียว (under-fetching) สำหรับระบบที่ซับซ้อน บางทีอาจต้องพิจารณาใช้การส่งข้อมูลแบบอื่นแทน เช่น GraphQL เป็นต้น

ไม่มีมาตรฐานตายตัว REST เป็นแค่ style ไม่ใช่ spec ที่เป็นทางการ แต่ละทีมอาจออกแบบ API ต่างกัน จนทำให้สับสนเมื่อเทียบกับระบบอื่นได้

Real-time ทำได้แต่ไม่ถนัด ถ้าต้องการ push ข้อมูลจาก server ไปหา client แบบ real-time (เช่น แชท หรือ live notification) REST ต้องพึ่ง polling หรือ long-polling ซึ่งทำงานได้ไม่ดีเท่า WebSocket

🧭 เมื่อไหร่ควรใช้ REST และเมื่อไหร่ไม่ควร#

ใช้ REST เมื่อ:

• งาน CRUD ทั่วไป (สร้าง อ่าน แก้ไข ลบ)
• API สาธารณะที่ต้องให้คนอื่นมาใช้ (เพราะ REST เข้าใจง่ายที่สุด)
• ทีมเพิ่งเริ่ม หรืองบจำกัด เพราะ learning curve ต่ำ

พิจารณาทางเลือกอื่นเมื่อ:

• ข้อมูลซับซ้อน มี relation เยอะ และ client ต้องการ query ยืดหยุ่น → GraphQL น่าสนใจกว่า
• ต้องการ performance สูงสุดและ binary protocol → gRPC เป็นตัวเลือก
• ระบบ real-time เช่น game, chat, collaborative tool → WebSocket เหมาะกว่า

📝 สรุป#

API คือข้อกำหนด (สัญญา) ที่ทำให้ระบบสองฝั่งคุยกันได้โดยไม่ต้องรู้โครงสร้างโค้ดและระบบภายในของกันและกัน

REST คือรูปแบบหนึ่งที่ได้รับความนิยมในงาน web เพราะเรียบง่าย ต่อยอดจาก HTTP และมีเครื่องมือรองรับอย่างครบถ้วน

ถ้าเพิ่งเริ่มสร้าง backend หรือกำลังออกแบบ API ตัวแรก REST เป็นจุดเริ่มต้นที่ดีมาก เรียนรู้ไม่นานก็สามารถใช้งานได้จริง

😎 ☕