หากคุณต้องการสร้าง API endpoint ปลอมที่ส่งคืน JSON, status code และ header ตามที่กำหนด โดยไม่ต้องตั้งเซิร์ฟเวอร์เอง Mocky เป็นตัวเลือกที่เริ่มต้นได้เร็ว บทความนี้จะพาคุณดูว่า Mocky คืออะไร ใช้งานอย่างไร เหมาะกับกรณีไหน และควรย้ายไปใช้เครื่องมือ mock API ที่ครบกว่านี้เมื่อใด หากต้องการภาพรวมเพิ่มเติม ดูการเปรียบเทียบ เครื่องมือจำลอง API ออนไลน์ และ ที่เก็บโอเพนซอร์สของ Mocky
Mocky คืออะไร?
Mocky เป็นเว็บบริการโอเพนซอร์สฟรีสำหรับสร้าง HTTP response แบบกำหนดเอง คุณกำหนด response ในเบราว์เซอร์ จากนั้น Mocky จะสร้าง URL เฉพาะให้ เมื่อมี request มายัง URL นั้น Mocky จะส่งคืน response ตามที่คุณตั้งไว้ทันที
ไม่ต้องเขียน backend ไม่ต้อง deploy server และไม่ต้องสร้างบัญชีสำหรับกรณีพื้นฐาน
Mocky สร้างโดย Julien Lafont ภายใต้ใบอนุญาต Apache 2.0 เวอร์ชันโฮสต์อยู่ที่ mocky.io และเนื่องจากโค้ดเป็นสาธารณะ คุณสามารถ self-host ได้หากต้องการควบคุม instance เอง
แนวคิดหลักคือ “ออกแบบ response แล้วผูกไว้กับ URL” ซึ่งเป็นจุดแข็งและข้อจำกัดของ Mocky ในเวลาเดียวกัน
สิ่งที่ Mocky กำหนดค่าได้
Mocky เหมาะสำหรับทดสอบ client เพราะคุณสามารถกำหนดส่วนสำคัญของ HTTP response ได้ เช่น
-
Status code เช่น
200,404,500 - Response body เช่น JSON หรือข้อความทั่วไป
-
HTTP headers เช่น
Content-Typeหรือ custom header - Response delay สำหรับจำลอง network ช้าหรือ backend ตอบช้า
เมื่อบันทึกแล้ว Mocky จะจัดเก็บ response และให้ URL ถาวร คุณสามารถนำ URL นี้ไปใช้ใน frontend, test script หรือ HTTP client ได้ทันที
ตัวอย่าง: สร้าง mock user endpoint ด้วย Mocky
สมมติว่า backend ยังไม่พร้อม แต่ frontend ต้องการ endpoint สำหรับดึงข้อมูลผู้ใช้
ตั้งค่าใน Mocky ดังนี้:
- Method/request URL: ใช้ URL ที่ Mocky สร้างให้
- Status code:
200 - Header:
Content-Type: application/json - Body:
{
"id": 42,
"name": "Ada Lovelace",
"role": "admin"
}
Mocky จะให้ URL รูปแบบนี้:
https://run.mocky.io/v3/<some-id>
จากนั้นใน frontend สามารถเรียกใช้ได้ เช่น:
const res = await fetch("https://run.mocky.io/v3/<some-id>");
const user = await res.json();
console.log(user.name);
ทุก request ไปยัง URL นี้จะได้ response เดิมกลับมาเสมอ สำหรับแนวทางเพิ่มเติม ดูบทความ วิธีการจำลอง API ออนไลน์โดยไม่ต้องตั้งค่าเซิร์ฟเวอร์
เมื่อไหร่ที่ Mocky เหมาะสม
ใช้ Mocky เมื่อคุณต้องการ mock แบบเร็วและตรงไปตรงมา เช่น:
- ต้องการ static response เพียงรายการเดียว
- ต้องการแชร์ payload คงที่กับทีม หรือแนบใน bug/support ticket
- ต้องการจำลอง error case เดี่ยว เช่น 500 Internal Server Error
- ไม่ต้องการให้ response เปลี่ยนตาม request
- ไม่ต้องการจัดการหลาย endpoint ในโปรเจกต์เดียว
สำหรับงานเหล่านี้ Mocky ใช้ง่ายมาก เปิดเว็บ ตั้งค่า response แล้วได้ URL ใช้งานภายในไม่กี่นาที
จุดที่ Mocky เริ่มไม่พอ
Mocky แต่ละ URL คือ static response หนึ่งรายการ เมื่อโปรเจกต์โตขึ้น ข้อจำกัดจะชัดเจนขึ้น:
ไม่มีข้อมูลแบบไดนามิก
ทุก request ได้ body เดิมเสมอ เช่น ไม่สามารถให้/users/1และ/users/2คืนข้อมูลคนละชุดจาก mock เดียวกันได้ไม่มี request matching
Mocky ไม่แยก response ตาม query parameter, path variable หรือ request bodyจัดระเบียบหลาย endpoint ยาก
API จริงมักมีหลายสิบ endpoint ถ้าใช้ Mocky จะกลายเป็นลิงก์หลายชุดที่ไม่เชื่อมกันการทำงานร่วมกันจำกัด
ไม่มี workspace, versioning หรือ permission สำหรับทีมไม่ผูกกับ schema/OpenAPI
mock response และ API spec อยู่คนละที่ ทำให้ drift ได้ง่าย
เมื่อคุณเริ่มเจอปัญหาเหล่านี้ 2–3 ข้อ แปลว่า static mock URL อาจไม่พอแล้ว และควรพิจารณา mock server หรือแพลตฟอร์มที่จัดการ API mock ได้ครบกว่า หากกำลังเทียบงบประมาณ ดู คู่มือเซิร์ฟเวอร์ mock API ฟรีและราคาถูก
ตัวอย่างสถานการณ์ที่พบบ่อย:
- Developer A mock endpoint ผู้ใช้
- Developer B mock endpoint รายการคำสั่งซื้อ
- Developer C mock endpoint authentication
ใน Mocky สิ่งเหล่านี้คือ URL แยกกัน ไม่มี base URL ร่วม และสลับ environment ยาก แต่ใน mock server ที่เป็นโปรเจกต์เดียวกัน คุณสามารถมี endpoint ทั้งหมดอยู่ภายใต้ host เดียว และจัดการ response/schema ร่วมกันได้
ทางเลือก Mocky ที่ดีที่สุด: Apidog
Apidog รองรับ use case แบบเดียวกับ Mocky คือสร้าง response แบบกำหนดเองไว้หลัง URL ที่แชร์ได้ แต่เพิ่มความสามารถสำหรับงานระดับโปรเจกต์ เช่น ข้อมูลแบบไดนามิก, schema-first mocking, หลาย endpoint ใน workspace เดียว และการทำงานร่วมกันเป็นทีม
ความแตกต่างหลักคือ:
- Mocky เหมาะกับคำถาม: “ขอ static response หนึ่งรายการแบบเร็วและฟรี”
- Apidog เหมาะกับคำถาม: “ขอ mock API ทั้งโปรเจกต์ที่เติบโตไปพร้อมกับทีมและ schema”
สิ่งที่ Apidog เพิ่มจากกรณีใช้งานของ Mocky:
Smart mock และข้อมูลที่สร้างโดย AI
Apidog สามารถสร้างค่าที่สมจริงจากชื่อ field และ schema เช่นemailคืนค่าอีเมล หรือcreatedAtคืนค่าวันที่รองรับ Faker.js
ใช้ Faker.js เพื่อสร้างข้อมูล mock แบบไดนามิก ทำให้ payload เปลี่ยนและสมจริงขึ้นในแต่ละ requestกฎ mock ขั้นสูง
ส่ง response ต่างกันตาม query parameter หรือ request body ได้Schema-first mocking
mock สร้างจาก OpenAPI/schema ทำให้ response และ API design ซิงก์กันTeam workspace
mock อยู่ในโปรเจกต์ร่วม มีการจัดการเวอร์ชันและการซิงก์ ไม่กระจัดกระจายเป็นลิงก์ครั้งเดียว
หากคุณแค่ต้องการ endpoint เดียวที่คืน 200 พร้อม JSON คงที่ Apidog ก็ทำได้เช่นกัน แต่ยังสามารถขยายต่อเป็น mock server สำหรับทั้งโปรเจกต์ได้เมื่อทีมต้องการมากขึ้น
Mocky vs Apidog: ภาพรวม
| ความสามารถ | Mocky | Apidog |
|---|---|---|
| กำหนด status code, header และ body หลัง URL | มี | มี |
| เริ่มใช้งานฟรี ไม่ต้องตั้งค่าเยอะ | มี | มี (แพลนฟรี) |
| Static response เดี่ยว | มี | มี |
| ข้อมูลแบบไดนามิก เช่น Faker.js, smart mock | ไม่มี | มี |
| Request matching / conditional rule | ไม่มี | มี |
| หลาย endpoint ในโปรเจกต์เดียว | ไม่มี | มี |
| Mock ที่ขับเคลื่อนด้วย schema/OpenAPI | ไม่มี | มี |
| Team workspace + version control | ไม่มี | มี |
| ตัวเลือก self-host | มี (โอเพนซอร์ส) | Cloud + ตัวเลือก self-host |
หากต้องการเปรียบเทียบเครื่องมือเพิ่มเติม ดู เครื่องมือจำลอง API ที่ดีที่สุด และ เครื่องมือจำลองปลายทาง REST
วิธีแทนที่ URL ของ Mocky ด้วย Apidog
การย้ายจาก Mocky URL เดี่ยวไป Apidog ทำได้เป็นขั้นตอน:
- ดาวน์โหลด Apidog และสร้างโปรเจกต์
- เพิ่ม endpoint เช่น
GET /users/42 - กำหนด response:
- Status code:
200 - Header:
Content-Type: application/json - Body:
- Status code:
{
"id": 42,
"name": "Ada Lovelace",
"role": "admin"
}
- เปิดใช้งาน mock server ใน Apidog
- คัดลอก mock URL ที่ Apidog สร้างให้
- เปลี่ยน frontend/test ให้เรียก URL ใหม่แทน Mocky
ตัวอย่าง:
const res = await fetch("https://<apidog-mock-host>/users/42");
const user = await res.json();
console.log(user);
หลังจากนั้นคุณสามารถเพิ่มความสามารถอื่นได้ทีละส่วน เช่น:
- เพิ่ม endpoint อื่นในโปรเจกต์เดียว
- ใช้ Faker.js สำหรับข้อมูลไดนามิก
- ตั้ง conditional response ตาม query/body
- import OpenAPI spec เพื่อสร้าง mock หลาย endpoint พร้อมกัน
ไม่จำเป็นต้องใช้ฟีเจอร์ขั้นสูงตั้งแต่วันแรก ทีมส่วนใหญ่จะค่อยๆ ย้าย endpoint สำคัญจาก Mocky ไป Apidog แล้วค่อยเลิกใช้ URL เก่าเมื่อทุกอย่างรวมอยู่ในโปรเจกต์เดียว
คำถามที่พบบ่อย
Mocky ฟรีหรือไม่?
ฟรี Mocky เป็นโอเพนซอร์สภายใต้ Apache 2.0 และไม่จำเป็นต้องมีบัญชีสำหรับสร้าง mock response พื้นฐาน URL ที่ได้จะถูกจัดเก็บฝั่งเซิร์ฟเวอร์และสามารถใช้งานต่อได้
หากต้องการมากกว่า static response เดี่ยว เช่น ข้อมูลไดนามิกหรือ workspace สำหรับทีม เครื่องมืออย่าง Apidog มีแพลนฟรีและฟีเจอร์ mock API ที่ครบกว่า
อะไรคือความแตกต่างระหว่าง mocky.io กับ mock server?
Mocky URL คือ response สำเร็จรูปหนึ่งรายการ ส่วน mock server จำลอง API ทั้งระบบได้ โดยรองรับหลาย endpoint, request matching และข้อมูลที่เปลี่ยนตาม request ได้
หากต้องการพื้นฐานเพิ่มเติม อ่านบทความ mock API คืออะไร
Mocky ส่งคืน status code และ header แบบกำหนดเองได้ไหม?
ได้ นี่คือ use case หลักของ Mocky คุณสามารถตั้ง status code, เพิ่ม header และเขียน body ได้เอง จากนั้น Mocky จะให้บริการทั้งหมดผ่าน URL เดียว
ข้อจำกัดคือ response จะเหมือนเดิมเสมอ ไม่ว่าจะส่ง request แบบใดก็ตาม
ควรเปลี่ยนจาก Mocky ไปใช้แพลตฟอร์ม mock ที่สมบูรณ์เมื่อใด?
เปลี่ยนเมื่อคุณต้องการสิ่งเหล่านี้:
- ข้อมูลแบบไดนามิกหรือสมจริง
- response ที่เปลี่ยนตาม query/body/path
- หลาย endpoint ในโปรเจกต์เดียว
- workspace สำหรับทีม
- mock ที่ซิงก์กับ OpenAPI/schema
ถ้ายังต้องการแค่ static response หนึ่งรายการ Mocky ยังเป็นตัวเลือกที่เรียบง่ายและเหมาะสม
สรุป
Mocky เป็นวิธีที่เร็วและฟรีในการสร้าง HTTP response แบบกำหนดเองหลัง URL เหมาะกับ static mock, error case เดี่ยว หรือการแชร์ payload อย่างรวดเร็ว
แต่เมื่อ API เริ่มมีหลาย endpoint, ต้องการข้อมูลไดนามิก, request matching, schema-first workflow หรือการทำงานร่วมกันเป็นทีม static URL เดี่ยวจะเริ่มไม่พอ
จุดนั้นคือพื้นที่ของ Apidog: เริ่มจากงานแบบเดียวกับ Mocky ได้ แต่ขยายต่อเป็น mock API ที่ผูกกับ schema ทำงานเป็นทีม และรองรับโปรเจกต์จริงได้ดีกว่า ดาวน์โหลด Apidog เพื่อสร้าง mock URL แรกของคุณได้ฟรี
Top comments (0)