Mock API Server — คู่มือการใช้งาน

1. กด Add endpoints แล้วเลือกสร้างเอง, import spec หรือเชื่อม repository
2. คัดลอกค่า Copy .env ไปใส่ใน frontend
3. เลือก endpoint แล้วกด Send เพื่อตรวจว่า mock ตอบตามที่ตั้งไว้
4. ถ้า response ไม่ตรง schema ให้กด Fix with AI → วาง error/schema → Preview → Apply & Test

1. กด Add endpoints → Connect repository → Choose repository
2. Chrome จะแสดง permission dialog ของ browser ให้กด Allow เพื่ออนุญาตแบบ read-only หน้าต่างนี้เป็นระบบความปลอดภัยของ Chrome เว็บเปลี่ยนหน้าตาไม่ได้
3. Mockbase scan ในเครื่องเพื่อหา HTTP calls, route constants และ import graph โดยข้าม node_modules, Git history, build, coverage และ assets
4. ระบบตาม route ไปยัง service/hook แล้วอ่าน TypeScript interface/type และ Zod schema เพื่อสร้าง request/response

เมื่อ endpoint มีอยู่แล้ว

• Merge missing fields — ค่าเริ่มต้น เก็บ mock เดิมและเติมสิ่งที่ขาด
• Keep current unchanged — ข้าม endpoint ที่ซ้ำ
• Replace with imported — ใช้ข้อมูลใหม่ แต่รักษา endpoint ID เดิม

AI ส่งเฉพาะ endpoint/context ที่เลือก ไม่ส่งทั้ง repo; cache ช่วยลดการเรียกซ้ำและ token cost

ข้อมูลและความเป็นส่วนตัว

• สิทธิ์ repository เป็น read-only; Mockbase ไม่เขียน ลบ commit หรือ push
• ไฟล์ถูก scan ใน browser ก่อนเลือก source ที่เกี่ยวข้องสูงสุด 60 ไฟล์
• อย่าเก็บ API keys/secrets ใน source; ใช้ไฟล์ environment ที่ถูก ignore และหมุน key ทันทีหากเคยเผยแพร่
• workspace และ AI cache เก็บฝั่ง server ใน .mockbase-data ซึ่งถูก ignore จาก Git

ปัญหาที่พบบ่อย

เปิดเว็บครั้งแรก ระบบสร้าง token ให้อัตโนมัติ URL ส่วนตัวของคุณคือ (คัดลอกไปใช้ได้ทันที):

URL นี้อ้างอิงจากโดเมนที่คุณกำลังเปิดอยู่จริง — เปิดหน้านี้บนเว็บที่ deploy แล้ว มันจะแสดงโดเมน production ให้เอง (เช่น https://your-app.onrender.com/mock/…)

• token เก็บในเบราว์เซอร์ของคุณ (localStorage) — คนอื่นเปิดเว็บเดียวกันจะได้คนละ token ไม่ชนกัน
• ตั้งชื่อ token เองได้ (เช่น my-team) โดยคลิกแก้ที่แถบ URL บนสุดของ Dashboard เพื่อให้จำง่ายและแชร์ทีมได้
• เปลี่ยน token = เปลี่ยน URL — endpoint ชุดเดิมจะย้ายไปที่ workspace ใหม่ให้อัตโนมัติ

กดปุ่ม Copy .env บนแถบ URL ของ Dashboard แล้ววางลงในโปรเจกต์ frontend:

จากนั้นเรียก API ได้ตามปกติ — CORS เปิดไว้ให้แล้ว ยิงจาก origin ไหนก็ได้:

const base = process.env.NEXT_PUBLIC_API_BASE_URL;
await fetch(`${base}/api/products`);   // → ได้ข้อมูล mock ทันที

• Import ไฟล์สเปค — ลาก/วางไฟล์ .csv .xlsx ลงกล่อง Import ระบบแปลงเป็น endpoint ให้อัตโนมัติ (รองรับ Excel หลายชีต)
• เพิ่มเอง — กดปุ่ม มุมขวาบน แล้วแก้ path / method / response
• หลาย response — ในแท็บ Response คลิก pill เพื่อสลับ response ที่เสิร์ฟ, + Add เพิ่ม, Edit แก้ JSON
• Generate ข้อมูลอัตโนมัติ — ปุ่ม Generate ในแท็บ Response สร้าง mock ให้ตามรูปทรง response (ปรับจำนวนแถวได้ที่ช่อง rows)
• Generate all (list → detail) — ถ้าเป็น detail endpoint (เช่น /business-units/:bu_id) ที่มีลิสต์คู่กัน ปุ่มจะเปลี่ยนเป็น Generate all (N) — สร้างข้อมูลครบทุก id ในลิสต์ พอคลิกเข้าไปแต่ละรายการก็มีข้อมูลของตัวเองครบ ไม่ซ้ำกัน
• ทดสอบ error — เติม ?__status=404 ท้าย URL เพื่อบังคับคืน response สถานะนั้น
• เปิด/ปิด — สลับ Toggle หน้า endpoint (ปิดแล้วคืน 404 ทันที)
• ลบ — ชี้ที่ endpoint ในลิสต์แล้วกดไอคอนถังขยะ หรือกดปุ่ม Delete ในแผงรายละเอียดทางขวา

ทุกการแก้ไขเซฟอัตโนมัติ (ในเบราว์เซอร์ + sync ขึ้น server) ไม่ต้องกด Save

แท็บ Config คือที่ตั้งค่า พฤติกรรม ของ endpoint ที่เลือกอยู่ · เปิดได้จากแผงขวา คลิกที่ endpoint แล้วกดแท็บ Config · ด้านล่างไล่อธิบาย ทุกช่องจากบนลงล่าง ว่าคืออะไรและกรอกยังไง

1) Endpoint (Method + Path)

ช่องซ้ายเลือก method (GET/POST/…) ช่องขวาคือ path · ใช้ :ชื่อ สำหรับ path param เช่น /business-units/:id · ถ้ามี gateway prefix เช่น /bff/pcp ระบบจับให้เองไม่ต้องใส่

2) Full URL

URL เต็มของ endpoint นี้ (มี token ต่อท้ายให้แล้ว) กดไอคอนคัดลอกเอาไปยิงทดสอบ/แปะให้ frontend ได้เลย

3) Serving (เปิด/ปิด)

สลับ Toggle · On = เสิร์ฟตามปกติ, Off = endpoint นี้คืน 404 ทันที (ไว้ทดสอบตอน API ยังไม่พร้อม โดยไม่ต้องลบทิ้ง)

4) Latency (ms)

หน่วงเวลาก่อนตอบ (มิลลิวินาที) · ใส่ 2000 = ตอบช้า 2 วินาที ไว้ทดสอบ loading state / spinner ของหน้าจอ

5) List query — ค้นหา / เรียง / แบ่งหน้า

เปิด Toggle เพื่อให้ response array ถูกกรอง/แบ่งหน้าจาก query จริง (ปิด = คืน array เต็ม) · แต่ละช่อง:

เปิด Toggle ครั้งแรกระบบเดาค่าให้อัตโนมัติ — แค่แก้ Search fields ให้ตรง · ดูตัวอย่างเต็มที่หัวข้อ “List query”

6) Conditional responses (Rules)

ให้ endpoint ตอบคนละ response variant ตามเงื่อนไขของ request · กด Add rule แล้วตั้ง:

หลายกฎเช็คบนลงล่าง เจอตัวแรกที่ตรงชนะ · ไม่ตรงเลย → เสิร์ฟ response ที่ active · Rules ไม่ได้กรองรายการในลิสต์ (การค้นหาให้ใช้ List query) · ดูตัวอย่างที่หัวข้อ “Conditional Response”

7) Write-through (เฉพาะ POST / PUT / PATCH)

ให้ทุกครั้งที่ยิงสำเร็จ นำ body ที่ส่งมา บันทึกลง response ของ endpoint อื่น — เช่น POST สร้างข้อมูลแล้วไปโผล่ใน GET ที่ list · เปิด Toggle แล้วตั้ง:

ทำให้ mock ทำตัวเหมือนมีฐานข้อมูลจริง — สร้าง/แก้แล้วเห็นผลใน list ทันที

ใส่ ตัวแปร ลงไปในค่าของ response JSON ได้เลย (แก้ที่แท็บ Response → Edit) แล้วระบบจะแทนที่ด้วยค่าจริงจาก request ตอนถูกเรียก — ใช้ได้ทุก method รวมถึง GET (ไม่จำเป็นต้องมี request body):

• {{query.ชื่อ}} — ค่าจาก query string เช่น ?type=A
• {{body.ชื่อ}} — ค่าจาก request body (เจาะลึกได้ เช่น {{body.user.name}})
• {{header.ชื่อ}} — ค่าจาก request header (ไม่สนตัวพิมพ์เล็ก/ใหญ่)
• {{param.ชื่อ}} — ค่าจาก path param เช่น /users/:id

ตัวอย่าง — response ที่ตั้งไว้แบบนี้:

{
  "userId": "{{param.id}}",
  "keyword": "{{query.q}}",
  "greeting": "สวัสดีคุณ {{body.name}}",
  "limit": "{{body.limit}}"
}

เมื่อยิง POST /users/42?q=phone พร้อม body {"name":"เอ","limit":10} จะได้:

{
  "userId": "42",
  "keyword": "phone",
  "greeting": "สวัสดีคุณ เอ",
  "limit": 10
}

เกร็ด: ถ้าทั้งช่องเป็นตัวแปรตัวเดียว (เช่น "{{body.limit}}") จะคง ชนิดข้อมูลจริงจาก body ให้ (ได้เลข 10 ไม่ใช่ "10", รวมถึง object/array/boolean) · ส่วน query / param / header มาจาก URL/HTTP จึงเป็น ข้อความ (string) เสมอ · ตัวแปรที่อยู่ปนกับข้อความจะกลายเป็นสตริง · ถ้าหาค่าไม่เจอ จะทิ้ง {{...}} ไว้ให้เห็น (จะได้รู้ว่าพิมพ์ผิด)

หมายเหตุ: สำหรับ POST / PUT / PATCH ระบบยัง merge body ที่ส่งมา ลงใน response ให้อัตโนมัติอยู่แล้ว (field ที่ส่งมาจะทับ/เพิ่มลงในผลลัพธ์) — ตัวแปร {{ }} ไว้ใช้เมื่ออยากจัดวางค่าลงตำแหน่งที่ต้องการเอง

อยากให้ endpoint เดียว ตอบคนละแบบ ตาม request เช่น ?role=admin ให้ข้อมูลเต็ม, ไม่มี token ให้ 401 — ทำได้ที่แท็บ Config → Conditional responses

• ไปที่แท็บ Response สร้าง response variant ให้ครบก่อน (เช่นตัว Success 200 กับตัว Unauthorized 401) — ต้องมีอย่างน้อย 2 ตัว
• ไปแท็บ Config → หัวข้อ Conditional responses → กด Add rule
• ตั้งเงื่อนไข: เลือกแหล่ง (query / body / header / path param), ใส่ชื่อ key, เลือกตัวเทียบ (equals, contains, exists, ...) และค่า
• เลือกว่า ถ้าเงื่อนไขครบ ให้เสิร์ฟ response ตัวไหน
• กด add condition เพื่อเพิ่มเงื่อนไขในกฎเดียว (ต้องเป็นจริง ทุกข้อ = AND)

ถ้าไม่มีกฎไหนตรง จะเสิร์ฟ response ที่ active อยู่ (แท็บ Response) ตามปกติ · ยังใช้ ?__status=404 บังคับสถานะทับทุกกฎได้เหมือนเดิม · ผสมกับตัวแปร {{ }} ในหัวข้อก่อนหน้าได้ (เลือก variant ด้วยกฎ แล้วเติมค่าจาก request ด้วยตัวแปร)

ตัวอย่างจริงครบทุกกรณี — ทำ 3 ขั้นตามนี้ในแต่ละ endpoint: (1) ตั้ง Request, (2) วาง Response ที่แท็บ Response → Edit, (3) กด Send เพื่อดูผล · จำไว้ว่า {{ }} ใส่ที่ Response เท่านั้น ส่วน Request Body เป็น JSON ธรรมดา

{
  "total": 2,
  "data": [
    { "id": 1, "name": "สำนักงานใหญ่" },
    { "id": 2, "name": "สาขาเหนือ" }
  ]
}

{
  "total": 2,
  "data": [
    { "id": 1, "name": "สำนักงานใหญ่" },
    { "id": 2, "name": "สาขาเหนือ" }
  ]
}

{
  "keyword": "{{query.search}}",
  "page": "{{query.page}}",
  "pageSize": "{{query.pageSize}}",
  "data": []
}

{
  "keyword": "Central",
  "page": "1",
  "pageSize": "10",
  "data": []
}

{
  "id": "{{param.id}}",
  "name": "หน่วยธุรกิจ {{param.id}}",
  "active": true
}

{
  "id": "42",
  "name": "หน่วยธุรกิจ 42",
  "active": true
}

{
  "name": "สาขาใหม่",
  "code": "BU-99"
}

{
  "id": 100,
  "status": "created"
}

{
  "id": 100,
  "status": "created",
  "name": "สาขาใหม่",
  "code": "BU-99"
}

{
  "name": "แก้ชื่อแล้ว"
}

{
  "id": "{{param.id}}",
  "name": "{{body.name}}",
  "updated": true
}

{
  "id": "42",
  "name": "แก้ชื่อแล้ว",
  "updated": true
}

{
  "authHeader": "{{header.authorization}}",
  "role": "user"
}

{
  "authHeader": "Bearer abc.xyz",
  "role": "user"
}

// ต้องมี 2 response variants:
//   Default · 200  →  { "tier": "default" }
//   Unauthorized · 401  →  { "error": "no token" }
// Rules (Config tab):
//   ถ้า header x-token is absent → เสิร์ฟ Unauthorized · 401

GET /data              → 401 { "error": "no token" }
GET /data (x-token: a) → 200 { "tier": "default" }

// ไม่ต้องแก้อะไร — แค่เติม ?__status=<เลขสถานะ> ท้าย URL
// ระบบจะคืน response variant ที่มีสถานะนั้น (ถ้ามี)

HTTP 500  (ใช้ทดสอบ error state ของ frontend)

ตัวแปร {{query.search}} แค่ สะท้อนค่ากลับ — ไม่ได้กรองข้อมูล · ถ้าอยากให้ mock ค้นหา / แบ่งหน้า / เรียงลำดับ array จริง ตาม query (เหมือน API หลังบ้านจริง) ให้เปิด List query ที่แท็บ Config

• ตั้ง response ให้มี array (เช่นใน data) และ object pagination ตามปกติ
• ไปแท็บ Config → หัวข้อ List query → เปิด Toggle (ระบบเดาค่าให้อัตโนมัติ: search/page/size/sortBy/sortDir, collection = data, pagination = pagination)
• แก้ Search fields ให้เป็น field ที่อยากให้ค้น เช่น buCode, nameTh (คั่นด้วย comma)
• ปรับชื่อ query param ให้ตรงกับที่ frontend ส่งจริง (เช่นบางที่ใช้ size บางที่ pageSize)

ตัวอย่าง — response ที่ตั้งไว้:

{
  "data": [
    { "id": 3041, "buCode": "CRCCC", "nameTh": "เซ็นทรัล รีเทล..." },
    { "id": 2,    "buCode": "0401",  "nameTh": "บริษัท เซ็นทรัล ฟู้ด..." },
    { "id": 3,    "buCode": "0601",  "nameTh": "บริษัท ซีอาร์ซี ไทวัสดุ..." }
    // ...รวม 60 รายการ
  ],
  "pagination": { "page": 1, "pageSize": 10, "totalItems": 60, "totalPages": 6 }
}

เมื่อยิง GET /business-units?search=CRC&page=1&size=10 (Search fields = buCode, nameTh) จะได้เฉพาะที่ตรง และ pagination อัปเดตตามจำนวนที่กรองได้จริง:

{
  "data": [
    { "id": 3041, "buCode": "CRCCC", "nameTh": "เซ็นทรัล รีเทล..." }
  ],
  "pagination": { "page": 1, "pageSize": 10, "totalItems": 1, "totalPages": 1 }
}

ค้นหาแบบ substring ไม่สนตัวพิมพ์เล็ก/ใหญ่ · ถ้าค้นแล้วไม่เจอเลย จะได้ data: [] และ totalItems: 0 (ไม่ใช่คืนมาทั้งหมดเหมือนก่อน) · ?sortBy=buCode&sortDir=desc เรียงลำดับให้ · ใช้ร่วมกับ Rules / ตัวแปร {{ }} ได้ · ปิด Toggle เมื่อไหร่ก็กลับไปคืน array เต็มเหมือนเดิม