API คืออะไร ต่างจากหน้าเว็บยังไง
API = หน้าประตูให้ program คุย program รู้จัก REST สไตล์การออกแบบยอดนิยม + endpoint pattern + เปรียบเทียบกับ GraphQL/gRPC
~8 นาที
7 บทที่ผ่านมาเราเรียน HTTP ครบทุกชิ้น: URL, method, status code, headers, body, JSON วันนี้จะเอาทุกอย่างมารวมกันที่คำสั้น ๆ ที่ได้ยินบ่อยมากในโลก software นั่นคือ API
หลายคนคิดว่า API เป็นเรื่องของโปรแกรมเมอร์เท่านั้น จริง ๆ ไม่ซับซ้อน มันคือ “หน้าประตู” ที่ให้ program คุยกับ program ผ่าน HTTP บทนี้จะทำให้เห็นทั้ง concept และรู้จัก REST ซึ่งเป็นสไตล์การออกแบบ API ที่นิยมที่สุด
API คืออะไร
- API = Application Programming Interface
- แปลตรงตัว: ช่องทางให้ application คุยกัน
- ถ้า GUI (graphical user interface) คือหน้าที่ คน ใช้ (ปุ่ม, ฟอร์ม, เมนู)API ก็คือหน้าที่ program ใช้ (URL, method, JSON)
- ใช้ HTTP เป็น transport ที่ใช้กันมากที่สุด เรียกกันว่า HTTP APIหรือ Web API
Mental model: ประตูร้านกับประตูคลังสินค้า
ร้านกาแฟมี 2 ประตู
- ประตูหน้า ลูกค้าเดินเข้ามา เห็นเมนู เลือกกาแฟ จ่ายเงิน ประตูนี้ออกแบบสำหรับ คน
- ประตูหลัง พนักงาน DHL มาส่งเมล็ดกาแฟ พนักงาน POS มาเช็คยอดขาย ประตูนี้ออกแบบสำหรับ ระบบอื่น
หน้าเว็บ (HTML) = ประตูหน้า, API (JSON) = ประตูหลัง โดยทั้ง 2 ประตูอาจติดอยู่กับร้านเดียวกัน แค่ออกแบบคนละแบบให้เหมาะกับผู้ใช้
API vs หน้าเว็บ ต่างกันตรงไหน
เว็บต้องการหน้า HTML สวย ๆ
Browser เปิดหน้าเว็บ
GET /menu/americano HTTP/1.1
Accept: text/html
↓ server เห็น Accept=html → เสิร์ฟหน้าเว็บ
Response: HTML (render)
Americano
4.8 · 80 ฿
- หน้าเว็บ response เป็น HTML + CSS + JS browser render ออกมาเป็น UI
- API response เป็น JSON (ส่วนใหญ่) program ของ client ทำ UI เองตามถนัด
- URL และ server อาจเป็นตัวเดียวกันก็ได้ ต่างแค่
AcceptและContent-Type
ทำไมต้องแยก API จากหน้าเว็บ
- Mobile app iOS/Android ไม่อยาก render HTML อยากได้ JSON มาทำ UI เอง
- Third-party integration เช่น LINE Notify ส่งแจ้งเตือนเมื่อมี order ใหม่ LINE ไม่ต้องการ HTML แค่ data
- Microservice server คุยกับ server กันเอง ไม่ต้องการ layout
- Multiple frontend web, mobile, watch, TV ใช้ API เดียวกัน เปลี่ยน UI ได้โดยไม่กระทบ server
REST style การออกแบบ API
- REST = Representational State Transfer
- นิยามโดย Roy Fielding ปี 2000 ในวิทยานิพนธ์ PhD ไม่ใช่ protocol ใหม่ แค่สไตล์การใช้ HTTP ให้เป็นมาตรฐาน
- API ที่ทำตาม REST เรียกว่า RESTful
หลักการหลักของ REST
- URL = noun ไม่ใช่ verbชี้ไปที่ “ของ” (resource) ไม่ใช่ “action”
- ✗
/getOrders,/createOrder - ✓
/orders(verb มาจาก HTTP method)
- ✗
- HTTP method = verb (ตามที่เรียนในบท 4) GET อ่าน POST สร้าง PATCH แก้ DELETE ลบ
- Stateless แต่ละ request อิสระ ไม่พึ่ง request ก่อนหน้า
- Status code มาตรฐาน ใช้ให้ตรงความหมาย ไม่ส่ง 200 พร้อม error ใน body
- JSON (ส่วนใหญ่) format มาตรฐานสำหรับ body
Endpoint ของแอพกาแฟในสไตล์ REST
สังเกต pattern: path เดียวกัน แต่ method ต่างกัน = action ต่างกัน
/menuเมนูของร้าน อ่านอย่างเดียว (ผู้ใช้ทั่วไปไม่แก้)
- GET
/menuดูรายการเมนูทั้งหมด - GET
/menu/{id}ดูรายละเอียดของเมนู 1 ชิ้น
/ordersorder ของผู้ใช้ CRUD ครบ
- GET
/ordersดู order ทั้งหมดของเรา - POST
/ordersสร้าง order ใหม่ - GET
/orders/{id}ดู order 1 ชิ้น - PATCH
/orders/{id}แก้บางส่วน เช่น size - DELETE
/orders/{id}ยกเลิก order
/users/{id}/favoritesnested resource ของเมนูโปรดของผู้ใช้
- GET
/users/{id}/favoritesดูเมนูโปรด - POST
/users/{id}/favoritesเพิ่มเมนูโปรด - DELETE
/users/{id}/favorites/{menuId}ลบเมนูโปรด 1 ชิ้น
Pattern REST: URL = noun (ของ), HTTP method = verb (จะทำอะไรกับของนั้น) ตัวอย่างเช่น
GET /ordersดูทั้งหมดPOST /ordersสร้างใหม่ ไม่ใช่/getOrdersPattern ที่เจอบ่อย
/resources= list หรือ createGET /ordersดูทั้งหมดPOST /ordersสร้างใหม่
/resources/{id}= CRUD บน 1 ชิ้นGET /orders/123ดูPATCH /orders/123แก้DELETE /orders/123ลบ
- Nested resources resources ที่อยู่ใน resource อื่น
GET /users/42/ordersorder ทั้งหมดของ user 42
- Query string สำหรับ filter, sort, paginate
GET /orders?status=pending&page=2&limit=20
นอก REST มีอะไรอีก
- RPC (Remote Procedure Call) URL ชี้ไปที่ action เช่น
/createOrder,/cancelOrderเก่ากว่า REST เจอใน API องค์กรเก่า - GraphQL ของ Facebook มี endpoint เดียว
/graphqlclient เขียน query ว่าอยากได้ field อะไรบ้าง เหมาะกับงาน frontend ที่ต้องการ flexibility - gRPC ของ Google binary (protobuf) เร็วและ type-safe ใช้ server-to-server ในระบบขนาดใหญ่
- WebSocket คุย 2 ทิศสดๆ สำหรับ chat, real-time
REST ยังครองส่วนแบ่งใหญ่ในโลก API เพราะ “ง่ายและใช้ HTTP ได้เต็มรูปแบบ”
คำศัพท์จากบทนี้
- API Application Programming Interface หน้าประตูให้ program คุยกัน
- HTTP API / Web API API ที่ใช้ HTTP เป็น transport
- REST สไตล์การออกแบบ API ที่ใช้ HTTP เต็มรูปแบบ
- RESTful API ที่ทำตามหลัก REST
- Endpoint URL เฉพาะที่รองรับ method ใด method หนึ่ง
- Resource “ของ” ที่ API ให้เข้าถึง เช่น order, user, menu
สรุป
- API = หน้าประตูให้ program คุยกับ program ผ่าน HTTP
- API ต่างจากหน้าเว็บตรง response format (JSON vs HTML)
- ใช้ API เพื่อให้ mobile/integration/microservice เข้าถึง data เดียวกัน
- REST = style การใช้ URL (noun) + HTTP method (verb) ให้เป็นมาตรฐาน
- Pattern ทั่วไป:
/resources,/resources/{id}, nested + query string - มีสไตล์อื่น (RPC, GraphQL, gRPC, WebSocket) ตามความเหมาะสม
ตอนนี้เราสร้าง API ได้แล้ว แต่ถ้าใครเข้ามาใน /orders ก็ดู order ของคนอื่นได้ไม่ได้ server ต้องรู้ว่า request นี้คือ “ใคร” ถึงจะให้เข้าถึงได้ถูกคน และข้อมูลที่ส่งระหว่าง client-server ก็ไม่ควรโดนคนกลางแอบอ่าน บทถัดไปเราจะเรียนเรื่อง Authentication และ HTTPS2 ชั้นความปลอดภัยที่ทุก API ต้องมี