HTTP เจาะลึก
เข้าใจ request/response, methods, status code และหลัก REST — รากฐานของทุก web API
ก่อนสร้าง web API เองต้องเข้าใจ HTTP — โพรโทคอลที่เว็บทั้งหมดใช้คุยกัน คุณเคยเรียก API ด้วย requests (บท 8) มาแล้ว หัวข้อนี้เจาะลึกฝั่งทฤษฎีเพื่อให้ออกแบบ API เองได้
Request / Response
เว็บทำงานแบบ client ส่ง request ไปหา server แล้ว server ตอบ response กลับ แต่ละ request มี method, path, headers และอาจมี body
Request: Response:
GET /users/1 HTTP/1.1 HTTP/1.1 200 OK
Host: api.example.com Content-Type: application/json
Authorization: Bearer xxx
{"id": 1, "name": "Aph"}HTTP Methods
method บอก "เจตนา" ของ request — REST ใช้ method ให้ตรงกับการกระทำกับ resource
| Method | ใช้ทำ | ตัวอย่าง |
|---|---|---|
| GET | ดึงข้อมูล | GET /users (เอารายชื่อ) |
| POST | สร้างใหม่ | POST /users (เพิ่มผู้ใช้) |
| PUT/PATCH | แก้ไข | PUT /users/1 |
| DELETE | ลบ | DELETE /users/1 |
Status Code
| ช่วง | หมายถึง | ที่เจอบ่อย |
|---|---|---|
| 2xx | สำเร็จ | 200 OK, 201 Created |
| 3xx | เปลี่ยนเส้นทาง | 301, 304 |
| 4xx | ผู้เรียกผิด | 400 Bad Request, 401, 403, 404 |
| 5xx | เซิร์ฟเวอร์ผิด | 500 Internal Error |
หลัก REST
REST คือแนวทางออกแบบ API รอบ "resource" (สิ่งของ) แล้วใช้ HTTP method กับมันให้ตรงความหมาย ทำให้ API คาดเดาได้และสม่ำเสมอ
GET /posts # เอาโพสต์ทั้งหมด
GET /posts/1 # เอาโพสต์ id 1
POST /posts # สร้างโพสต์ใหม่
PUT /posts/1 # แก้โพสต์ 1
DELETE /posts/1 # ลบโพสต์ 1อย่าใช้ GET สร้าง/ลบข้อมูล (GET ควรอ่านอย่างเดียว ไม่เปลี่ยนแปลงอะไร) การออกแบบ REST ที่ดีทำให้คนอื่นเดา API ของเราถูกโดยไม่ต้องอ่าน doc มาก
สรุปหัวข้อนี้
- เว็บ = client ส่ง request → server ตอบ response
- method: GET (อ่าน) / POST (สร้าง) / PUT-PATCH (แก้) / DELETE (ลบ)
- status: 2xx สำเร็จ, 4xx ผู้เรียกผิด, 5xx server ผิด
- REST = ออกแบบรอบ resource + ใช้ method ตรงความหมาย
1) ออกแบบ endpoint ของ blog API (resource posts) ครบ CRUD พร้อม method 2) บอก status code ที่เหมาะกับ: สร้างสำเร็จ / ไม่พบ / ไม่ได้ล็อกอิน 3) อธิบายว่าทำไมไม่ควรใช้ GET ลบข้อมูล 4) ออกแบบ endpoint สำหรับ comment ของแต่ละโพสต์