ส่วนใหญ่แปลว่า request สำเร็จ
`response.ok` จะเป็น `true` เมื่อ status อยู่ในช่วง 200-299
Fetch
ปูพื้นฐาน HTTP ให้เห็นภาพ request, response, status code, headers, body และ JSON ก่อนลงมือใช้ fetch() จริงในบทถัดไป
เวลา browser ขอข้อมูลจาก server ทั้งการเปิดหน้าเว็บ, โหลด API, ส่งฟอร์ม หรือกดลบรายการ เบื้องหลังมักคุยกันผ่าน **HTTP** มองแบบง่ายที่สุด HTTP คือกติกาว่า client จะส่งคำขอแบบไหน และ server จะตอบกลับอะไรให้บ้าง จึงเป็นพื้นฐานที่ต้องเข้าใจก่อนใช้ `fetch()` จริง
Browser (client)
-> ส่ง HTTP request ไปยัง URL
Server
-> ประมวลผล
-> ส่ง HTTP response กลับมา
Browser
-> ดู status, headers, body
-> นำข้อมูลไปแสดงผลหรือทำงานต่อ| ส่วนของ request | หน้าที่ | ตัวอย่าง |
|---|---|---|
| URL | บอกว่าจะคุยกับ resource ไหน | `/users/1`, `/todos?_limit=5` |
| Method | บอก intent ของคำขอ | `GET`, `POST`, `PATCH`, `DELETE` |
| Headers | ส่ง metadata เพิ่มเติม | `Content-Type`, `Authorization`, `Accept` |
| Body | ส่งข้อมูลไปกับคำขอเมื่อจำเป็น | JSON สำหรับสร้างหรือแก้ข้อมูล |
ไม่ใช่ทุก request จะมี body เสมอไป เช่น `GET` มักใช้แค่ URL กับ query parameters ส่วน `POST`, `PUT`, `PATCH` มักต้องมี body เพื่อส่งข้อมูลใหม่ไปให้ server
fetch("https://jsonplaceholder.typicode.com/todos/1");
// URL: /todos/1
// Method: GET
// Headers: browser ใส่พื้นฐานบางอย่างให้อัตโนมัติ
// Body: ไม่มี
fetch("https://jsonplaceholder.typicode.com/todos", {
method: "POST",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
title: "เรียน HTTP",
completed: false,
}),
});เมื่อ server ตอบกลับมา เราไม่ได้สนใจแค่ข้อมูลใน body อย่างเดียว แต่ต้องดูด้วยว่าคำขอนั้นสำเร็จหรือไม่ สำเร็จแบบไหน และ server ส่งข้อมูลประเภทใดกลับมา
| ส่วนของ response | ใช้ทำอะไร | สิ่งที่มักเช็ก |
|---|---|---|
| Status code | บอกผลระดับสูงของคำขอ | 200, 201, 204, 404, 500 |
| Headers | บอก metadata ของข้อมูลตอบกลับ | `content-type`, `cache-control` |
| Body | เป็นข้อมูลจริงที่เราจะใช้ต่อ | JSON, text, HTML, binary |
| กลุ่ม | ความหมาย | ตัวอย่างที่เจอบ่อย |
|---|---|---|
| 2xx | สำเร็จ | `200 OK`, `201 Created`, `204 No Content` |
| 4xx | คำขอมีปัญหาฝั่ง client หรือสิทธิ์ไม่พอ | `400 Bad Request`, `401 Unauthorized`, `404 Not Found` |
| 5xx | ปัญหาเกิดฝั่ง server | `500 Internal Server Error`, `503 Service Unavailable` |
จุดที่สำคัญมากสำหรับบท fetch คือ HTTP error อย่าง `404` หรือ `500` ไม่ได้แปลว่า network พังเสมอไป หลายครั้ง browser ยังรับ response กลับมาได้อยู่ เพียงแต่ status ไม่อยู่ในช่วงสำเร็จ
ใช้ภาพจำนี้ช่วยก่อนเข้าสู่บท fetch โดยตรง
`response.ok` จะเป็น `true` เมื่อ status อยู่ในช่วง 200-299
อาจเป็น URL ผิด, ข้อมูลไม่ครบ, หรือไม่มีสิทธิ์เข้าถึง resource
ปัญหาไม่ได้เกิดจาก syntax ของ fetch เสมอไป แต่อาจเป็นระบบปลายทาง
เวลาคุยกับ REST API เรามักส่งและรับข้อมูลเป็น **JSON** เพราะมันแทน object, array, string, number และ boolean ได้ตรงกับสิ่งที่ JavaScript ใช้งานอยู่แล้ว ดังนั้นเวลาใช้ fetch จริง pattern ที่เจอบ่อยมากคือ “รับ response มาก่อน แล้วแปลง body JSON ให้เป็น object ด้วย `response.json()`”
async function loadTodo() {
const response = await fetch(
"https://jsonplaceholder.typicode.com/todos/1"
);
if (!response.ok) {
throw new Error("โหลดข้อมูลไม่สำเร็จ");
}
const todo = await response.json();
console.log(todo.id);
console.log(todo.title);
console.log(todo.completed);
}
loadTodo();