DEV Community

Cover image for วิธี Mock API ใน Apidog โดยไม่ต้องเขียนโค้ด
Thanawat Wongchai
Thanawat Wongchai

Posted on • Originally published at apidog.com

วิธี Mock API ใน Apidog โดยไม่ต้องเขียนโค้ด

ทีมฟรอนต์เอนด์ของคุณติดขัดอยู่ เพราะแบ็กเอนด์สำหรับ GET /users และ GET /orders ยังไม่พร้อม แต่ UI ต้องใช้ข้อมูลสมจริงเพื่อทดสอบรายการ การแบ่งหน้า และสถานะว่างเปล่า วิธีเดิมคือเขียนไฟล์ JSON ปลอมเองและคอยแก้ทุกครั้งที่ฟิลด์เปลี่ยน ซึ่งทำให้ mock หลุดจาก API จริงได้ง่าย

ลองใช้ Apidog วันนี้

หากมี API specification อยู่แล้ว Apidog สามารถสร้าง mock จากสคีมาของเอนด์พอยต์ได้โดยไม่ต้องเขียนโค้ด ฟีเจอร์นี้เรียกว่า Smart Mock โดยจะอ่านชื่อฟิลด์และประเภทข้อมูลเพื่อสร้างข้อมูลที่ดูสมจริง เช่น name จะได้ชื่อ และ email จะได้อีเมล บทความนี้จะแสดงวิธีสร้าง mock สำหรับเอนด์พอยต์อีคอมเมิร์ซ 2 ตัว หา URL ของ mock ทำความเข้าใจลำดับความสำคัญของ response และปรับผลลัพธ์เมื่อ Smart Mock สร้างข้อมูลไม่ตรงความต้องการ หากต้องการทบทวนพื้นฐานก่อน อ่าน API mocking คืออะไรและทำงานอย่างไร และดูรายละเอียดข้อจำกัดของสคีมาได้ที่ JSON Schema

Smart Mock ทำอะไร และช่วยลดงานอย่างไร

ตามเอกสารของ Apidog ระบบ mock สามารถคืนค่า response ได้หลายรูปแบบ ได้แก่

  1. Smart Mock — สร้างข้อมูลอัตโนมัติจาก API spec
  2. Response Example — คืนค่าตัวอย่าง response ที่กำหนดไว้
  3. Custom Response — คืนค่าที่กำหนดเอง
  4. Conditional Mocking — เลือก response ตามพารามิเตอร์ของคำขอ
  5. Mock Scripts — สร้าง response ที่สัมพันธ์กับข้อมูลใน request

ภาพรวมตัวเลือก Mock ใน Apidog

Smart Mock เป็นตัวเลือกที่ไม่ต้องกำหนดค่าเพิ่มใน Apidog ตราบใดที่เอนด์พอยต์มี response schema ระบบจะเติมข้อมูลให้ทุกฟิลด์ตามสคีมาโดยอัตโนมัติ

ตัวอย่างเช่น หาก schema มีฟิลด์ดังนี้:

{
  "name": "string",
  "email": "string",
  "createdAt": "string",
  "isActive": "boolean"
}
Enter fullscreen mode Exit fullscreen mode

Smart Mock จะสร้างค่าที่สอดคล้องกับชื่อฟิลด์และประเภทข้อมูล แทนที่จะคืนสตริงหรือค่าทั่วไปทุกฟิลด์

ผลลัพธ์คือ เมื่อสคีมาเปลี่ยน mock จะเปลี่ยนตาม เพราะทั้งสองใช้แหล่งข้อมูลเดียวกัน

ก่อนเริ่ม: ต้องมี response schema

Smart Mock ต้องอ่าน response schema ของเอนด์พอยต์ หากไม่มีการกำหนด response ระบบจะไม่มีข้อมูลสำหรับสร้าง mock ที่มีประโยชน์

คุณสร้างสคีมาได้ 2 วิธีหลัก:

  • ออกแบบ API ใน Apidog แล้วเพิ่ม response schema ใน endpoint
  • นำเข้าไฟล์ OpenAPI ซึ่งโดยทั่วไปมี response schema ติดมาด้วย

หากจะใช้ Local Mock ต้องติดตั้ง Apidog desktop client เพราะ Local Mock ทำงานบนเครื่องและไม่พร้อมใช้งานใน Apidog Web ดาวน์โหลดได้ที่ ดาวน์โหลด Apidog

ทีละขั้นตอน: สร้าง mock สำหรับ GET /users และ GET /orders

ตัวอย่างนี้ใช้ API ร้านค้าแบบง่าย มี 2 เอนด์พอยต์:

  • GET /users
  • GET /orders

ขั้นตอนที่ 1: กำหนด response ของ GET /users

สร้างเอนด์พอยต์ GET /users แล้วกำหนด response body:

{
  "id": 1024,
  "name": "Amara Osei",
  "email": "amara.osei@example.com",
  "phone": "+1-415-555-0148",
  "createdAt": "2026-03-11T09:24:00Z",
  "isActive": true
}
Enter fullscreen mode Exit fullscreen mode

ตรวจสอบว่าแต่ละฟิลด์มีประเภทข้อมูลใน schema เช่น:

ฟิลด์ ประเภท
id integer
name string
email string
phone string
createdAt string
isActive boolean

ชื่อและประเภทของฟิลด์คือข้อมูลหลักที่ Smart Mock ใช้สร้างค่า

ขั้นตอนที่ 2: กำหนด response ของ GET /orders

สร้าง GET /orders และกำหนดให้ response เป็นอาร์เรย์:

[
  {
    "orderId": "ORD-58210",
    "userId": 1024,
    "total": 84.5,
    "currency": "USD",
    "status": "shipped",
    "createdAt": "2026-05-02T14:03:00Z"
  }
]
Enter fullscreen mode Exit fullscreen mode

สำหรับ response แบบรายการ ควรกำหนด schema ของ item ภายในอาร์เรย์ให้ครบ เพื่อให้ Smart Mock สร้างออบเจ็กต์คำสั่งซื้อได้อย่างถูกต้อง

ขั้นตอนที่ 3: คัดลอก URL ของ mock

Apidog สร้าง URL mock ให้เอนด์พอยต์อัตโนมัติ โดยตำแหน่งจะต่างกันตามโหมดที่ใช้งาน:

  • DESIGN mode: เปิดแท็บ API ใต้เอนด์พอยต์
  • DEBUG mode: เปิดแท็บ Mock

กด Click to copy เพื่อคัดลอก URL

การคัดลอกจะได้เฉพาะ URL หากเอนด์พอยต์ไม่ใช่ GET หรือจำเป็นต้องส่ง request body คุณต้องระบุ HTTP method และ body เองตอนเรียกใช้

Local Mock ใช้ 127.0.0.1 พอร์ต 4523 ตัวอย่าง URL แบบ path mode:

http://127.0.0.1:4523/m1/{projectID}-{versionNo}-{serverNo}/users
Enter fullscreen mode Exit fullscreen mode

หรือใช้ ID mode เพื่อชี้ไปยังเอนด์พอยต์ด้วย ID:

http://127.0.0.1:4523/m2/{projectID}-{versionNo}-{serverNo}/{endpointId}
Enter fullscreen mode Exit fullscreen mode

Local Mock จะเริ่มทำงานอัตโนมัติเมื่อเปิด Apidog desktop client

ขั้นตอนที่ 4: เรียก GET /users

เรียก mock ผ่าน curl:

curl http://127.0.0.1:4523/m1/1234567-0-0/users
Enter fullscreen mode Exit fullscreen mode

คุณอาจได้ response ลักษณะนี้:

{
  "id": 3187,
  "name": "Diego Marchetti",
  "email": "diego.marchetti@example.net",
  "phone": "+1-628-555-0113",
  "createdAt": "2026-01-27T18:41:22Z",
  "isActive": true
}
Enter fullscreen mode Exit fullscreen mode

สังเกตว่า:

  • name ดูเหมือนชื่อบุคคล
  • email อยู่ในรูปแบบอีเมล
  • createdAt เป็นค่าคล้ายเวลา ISO 8601
  • isActive เป็น boolean

พฤติกรรมนี้มาจาก Property Name Matching ระบบจะเทียบชื่อฟิลด์กับกฎที่มีอยู่ แล้วเลือกข้อมูลที่เหมาะสม

เมื่อส่งคำขอใหม่ ค่าที่สร้างแบบไดนามิกอาจเปลี่ยนไป ซึ่งช่วยทดสอบว่า UI รองรับข้อมูลหลากหลายได้จริง

ขั้นตอนที่ 5: เรียก GET /orders 

curl http://127.0.0.1:4523/m1/1234567-0-0/orders
Enter fullscreen mode Exit fullscreen mode

ผลลัพธ์จะเป็นรายการคำสั่งซื้อที่มีฟิลด์อย่างยอดรวม สถานะ สกุลเงิน และเวลา เหมาะสำหรับนำไปพัฒนาหน้ารายการคำสั่งซื้อได้ทันที

Smart Mock เลือกค่าแต่ละฟิลด์อย่างไร

Smart Mock ใช้ลำดับความสำคัญ 3 ระดับในการสร้างค่าให้พร็อพเพอร์ตี้:

  1. Mock Field
  2. Property Name Matching
  3. JSON Schema

1. Mock Field

หากกำหนด Mock Field ไว้ใน response spec ระบบจะใช้ค่านั้นก่อนเสมอ

Mock Field รองรับ 2 รูปแบบ:

  • Fixed value — คืนค่าเดิมทุกครั้ง
  • Faker statement — สร้างค่าหลากหลายตาม expression

ตัวอย่างการใช้งาน:

  • กำหนด currency เป็น Fixed value: USD
  • กำหนด status เป็น Faker statement ที่เลือกจาก shipped, pending, delivered

2. Property Name Matching

หากไม่มี Mock Field ระบบจะพิจารณาชื่อพร็อพเพอร์ตี้ เช่น:

  • email
  • phone
  • createdAt
  • name

Apidog จะใช้กฎ wildcard หรือ regular expression เพื่อสร้างข้อมูลให้ตรงความหมายของชื่อฟิลด์ คุณสามารถเพิ่มกฎของทีมเองได้ใน Mock Settings

3. JSON Schema

หากชื่อฟิลด์ไม่ตรงกับกฎใด Smart Mock จะย้อนกลับไปสร้างค่าตามประเภทและข้อจำกัดของ JSON Schema

ลำดับความสำคัญของการสร้างค่า Smart Mock

ข้อจำกัดของ JSON Schema ที่ Smart Mock เคารพ ได้แก่:

  • ความยาวสตริง
  • ค่า enum
  • ช่วงตัวเลข เช่น minimum และ maximum
  • ความยาวอาร์เรย์ เช่น minItems

ตัวอย่าง schema สำหรับ order:

{
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "enum": ["pending", "shipped", "delivered"]
    },
    "total": {
      "type": "number",
      "minimum": 1,
      "maximum": 10000
    },
    "items": {
      "type": "array",
      "minItems": 3
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

ด้วยสคีมานี้:

  • status จะเป็นหนึ่งใน 3 ค่าเท่านั้น
  • total จะอยู่ในช่วง 1–10000
  • items จะมีอย่างน้อย 3 รายการ

Apidog ยังรองรับ mock locales เพื่อสร้างข้อมูลตามภาษาและรูปแบบภูมิภาคที่แตกต่างกัน

เมื่อ Smart Mock สร้างข้อมูลไม่ตรงความต้องการ

Smart Mock อาศัยการอนุมาน จึงอาจไม่เข้าใจฟิลด์เฉพาะของโดเมน เช่น:

  • sku อาจได้สตริงทั่วไป
  • total อาจเป็นตัวเลขที่ไม่อยู่ในช่วงที่ต้องการ
  • status อาจไม่มีตัวเลือกที่ตรงกับระบบจริง

แก้ปัญหาตามลำดับนี้

1. ปรับ JSON Schema ก่อน

เพิ่มข้อจำกัดที่สะท้อนสัญญา API จริงให้มากขึ้น:

{
  "sku": {
    "type": "string",
    "pattern": "^SKU-[A-Z0-9]{6}$"
  },
  "status": {
    "type": "string",
    "enum": ["pending", "shipped", "delivered"]
  },
  "total": {
    "type": "number",
    "minimum": 0.01,
    "maximum": 99999.99
  }
}
Enter fullscreen mode Exit fullscreen mode

แนวทางนี้ดีที่สุดเมื่อกฎเป็นส่วนหนึ่งของ API contract เพราะ mock และการตรวจสอบสคีมาจะใช้ข้อกำหนดเดียวกัน

2. ตั้งค่า Mock Field

หาก schema ไม่สามารถอธิบายรูปแบบข้อมูลได้ชัดเจนพอ ให้กำหนด Mock Field:

  • ใช้ Fixed value สำหรับค่าไม่เปลี่ยน เช่น currency: "USD"
  • ใช้ Faker statement สำหรับข้อมูลที่ควรหลากหลายแต่ยังควบคุมได้

แนวคิด Faker ของ Apidog สอดคล้องกับ Mock.js และอ่านรายละเอียดไวยากรณ์เพิ่มเติมได้ที่ ใช้ Faker ใน Apidog

3. เพิ่ม Property Name Matching Rule

หากฟิลด์ชื่อเดิม เช่น sku ปรากฏในหลายเอนด์พอยต์ ให้เพิ่มกฎส่วนกลางเพียงครั้งเดียว:

  1. เปิด Settings
  2. ไปที่ General Settings
  3. เลือก Feature Settings
  4. เปิด Mock Settings
  5. กด New
  6. กำหนดเงื่อนไขให้ตรงกับชื่อฟิลด์
  7. กำหนด mock expression ที่ต้องการ

หลังจากนั้น sku ทุกตัวในโปรเจกต์จะใช้รูปแบบที่กำหนด แทนการคืนสตริงทั่วไป

ลำดับความสำคัญของ response mock

เมื่อเอนด์พอยต์มีทั้ง Mock Expectation, Response Example และ Smart Mock ระบบต้องเลือก response หนึ่งแบบ โดยตั้งค่าได้ที่:

Project Settings → Mock Settings → Default mock method

มี 2 ตัวเลือก:

  • Smart Mock First — ลำดับคือ Mock Expectation → Smart Mock
  • Response example first — ลำดับคือ Mock Expectation → Response Example → Smart Mock

กฎสำคัญคือ Mock Expectations มีความสำคัญสูงสุดเสมอ หากเงื่อนไขตรงกัน

ตัวอย่าง: หากตั้ง Mock Expectation ให้คืน 404 เมื่อ userId=9999 response นี้จะถูกเลือกก่อน Smart Mock และ Response Example เสมอ

สำหรับการตั้งค่า response แบบมีเงื่อนไข อ่าน สร้าง mock การตอบสนอง API แบบมีเงื่อนไขใน Apidog

สรุปลำดับการตัดสินใจ:

Mock Expectation
  ↓
Response Example หรือ Smart Mock
  ↓
Smart Mock fallback
Enter fullscreen mode Exit fullscreen mode

Local Mock, Cloud Mock และ Runner Mock

Smart Mock และ Custom Mock อธิบายวิธีสร้าง response ส่วน Local, Cloud และ Runner อธิบายตำแหน่งที่ mock ทำงาน

Local Mock

  • ทำงานบนเครื่องผ่าน Apidog desktop client
  • เริ่มอัตโนมัติเมื่อเปิด client
  • ใช้ 127.0.0.1:4523
  • ใช้ได้เฉพาะเมื่อ client เปิดอยู่
  • ไม่พร้อมใช้งานใน Apidog Web

หากอุปกรณ์อื่นในเครือข่ายต้องเรียกใช้ Local Mock ให้ใช้ LAN IP ของเครื่องแทน 127.0.0.1

Cloud Mock

  • โฮสต์บนเซิร์ฟเวอร์ของ Apidog
  • เข้าถึงได้ตลอด 24 ชั่วโมง 7 วัน
  • ต้องเปิดใช้งานจากการจัดการ environment
  • ใช้โดเมน https://mock.apidog.com
  • ใช้โครงสร้าง path แบบ m1 และ m2 เช่นเดียวกับ Local Mock
  • มีไว้สำหรับการทดสอบ ไม่ใช่ production traffic

Runner Mock

  • โฮสต์เองบนโครงสร้างพื้นฐานของทีม
  • แชร์การใช้งานภายในทีม
  • เหมาะกับองค์กรที่ต้องการให้ mock อยู่ภายในเครือข่ายของตน

เลือกใช้งานตามสถานการณ์:

สถานการณ์ ตัวเลือกที่เหมาะสม
พัฒนาฟรอนต์เอนด์บนเครื่องตัวเอง Local Mock
แชร์ mock ให้ทีม หรือ preview ที่ deploy แล้ว Cloud Mock
ต้องการโฮสต์ภายในโครงสร้างพื้นฐานขององค์กร Runner Mock

ดูเพิ่มเติมได้จาก การเปรียบเทียบเครื่องมือ mocking API ออนไลน์ และ คู่มือ Apidog Cloud Mock

ข้อควรระวังเรื่อง routing

มีรายละเอียด routing ที่ควรตรวจสอบก่อน debug เรื่อง response

Path ต้องขึ้นต้นด้วย /

กำหนด endpoint path เป็น:

/orders
Enter fullscreen mode Exit fullscreen mode

ไม่ใช่:

orders
Enter fullscreen mode Exit fullscreen mode

พาธที่ไม่ขึ้นต้นด้วย / อาจไม่ใช้ mock environment ตามที่คาดหวัง และพาธที่ไม่มี slash นำหน้าจะใช้ได้เฉพาะ ID mode

API ซ้ำ method และ path

หากมี API สองรายการที่ใช้ HTTP method และ path เดียวกัน path mode ไม่สามารถแยกความแตกต่างได้เอง

ให้เพิ่ม query parameter นี้:

?apidogApiId={endpointId}
Enter fullscreen mode Exit fullscreen mode

ตัวอย่าง:

http://127.0.0.1:4523/m1/1234567-0-0/orders?apidogApiId=98765
Enter fullscreen mode Exit fullscreen mode

รีเฟรชแล้วข้อมูลเปลี่ยน

ข้อมูล Smart Mock แบบไดนามิกจะถูกสร้างใหม่เมื่อส่งคำขอใหม่ หากเห็น response เดิมซ้ำกัน ให้ตรวจสอบว่าไม่ได้อ่านจาก cache

ทำให้เวิร์กโฟลว์ต่อเนื่องด้วย Apidog CLI

การให้บริการ mock เป็นความสามารถของ GUI และ cloud ใน Apidog ไม่ว่าจะเป็น Local Mock, Cloud Mock หรือ Runner Mock ส่วน Apidog CLI ไม่ได้ใช้สำหรับเริ่ม mock server จากเทอร์มินัล

บทบาทของ CLI คือช่วยให้ API schema ซึ่งเป็นแหล่งข้อมูลของ Smart Mock อัปเดตและถูกต้องเมื่อโปรเจกต์เปลี่ยนแปลง

เมื่อ frontend ใช้ mock เพื่อเดินหน้าพัฒนาได้แล้ว คุณสามารถรัน test scenario แบบ headless ใน CI เพื่อตรวจสอบ backend จริงกับ contract เดียวกันได้:

apidog run -t <scenario_id> -e <env_id> -r html,cli
Enter fullscreen mode Exit fullscreen mode

ติดตั้ง CLI:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Apidog CLI ต้องใช้ Node.js v16 หรือใหม่กว่า จากนั้นยืนยันตัวตนด้วย:

apidog login --with-token <your-token>
Enter fullscreen mode Exit fullscreen mode

นำคำสั่งไปใส่ใน CI pipeline ได้ทันที ดูตัวอย่างการตั้งค่าได้ที่ ใช้งาน Apidog ใน CI/CD pipeline

แนวคิดสำคัญคือ:

  • Smart Mock ช่วยให้ frontend ทำงานต่อได้ก่อน backend เสร็จ
  • schema ที่อัปเดตช่วยให้ mock สะท้อน API contract
  • CI ช่วยตรวจสอบว่า backend จริงยังสอดคล้องกับ contract เดียวกัน

คำถามที่พบบ่อย

ต้องเขียนโค้ดเพื่อใช้ Smart Mock หรือไม่?

ไม่ต้อง ตราบใดที่เอนด์พอยต์มี response schema Smart Mock จะสร้างข้อมูลให้อัตโนมัติ ใช้ Mock Field, Faker statement หรือ mock script เฉพาะเมื่อจำเป็นต้องควบคุมค่าบางฟิลด์

อ่านภาพรวมได้ที่ mock API

ทำไม mock URL ไม่คืนค่าอะไรเลย?

ตรวจสอบตามลำดับนี้:

  1. เอนด์พอยต์มี response schema หรือไม่
  2. path ขึ้นต้นด้วย / หรือไม่
  3. หากใช้ Local Mock เปิด Apidog desktop client อยู่หรือไม่
  4. URL, HTTP method และ request body ตรงกับเอนด์พอยต์หรือไม่

ทำให้ Smart Mock คืนค่าคงที่แทนข้อมูลสุ่มได้อย่างไร?

ตั้งค่า Mock Field ของพร็อพเพอร์ตี้:

  • ใช้ Fixed value สำหรับค่าคงที่
  • ใช้ Faker statement สำหรับข้อมูลที่หลากหลายแต่ควบคุมได้

Mock Field มีลำดับสูงกว่า Property Name Matching และค่า default จาก JSON Schema

เพื่อนร่วมทีมเรียก Local Mock บนเครื่องเราได้หรือไม่?

ทำได้เฉพาะผ่านเครือข่ายท้องถิ่น และต้องเปิด Apidog client อยู่ หากต้องการ URL ที่เข้าถึงได้ตลอด ให้ใช้ Cloud Mock ที่ https://mock.apidog.com

ถ้ามีทั้ง Response Example และ Smart Mock ระบบจะเลือกอะไร?

ขึ้นอยู่กับค่า Default mock method:

  • Smart Mock First: ใช้ Smart Mock หลังจากไม่พบ Mock Expectation ที่ตรงกัน
  • Response example first: ใช้ Response Example ก่อน แล้วจึงใช้ Smart Mock เป็น fallback

ไม่ว่าจะเลือกแบบใด Mock Expectation ที่ตรงเงื่อนไขจะมีลำดับสูงสุด

สรุป

Smart Mock ช่วยเปลี่ยน API schema ให้เป็น mock ที่เรียกใช้งานได้โดยไม่ต้องเขียนโค้ดหรือดูแลไฟล์ JSON ปลอมแยกต่างหาก

เวิร์กโฟลว์ที่ใช้งานได้จริงคือ:

  1. กำหนด response schema ให้ครบ
  2. คัดลอก mock URL จากแท็บ API หรือ Mock
  3. เรียก mock จาก frontend หรือ curl
  4. เพิ่มข้อจำกัด JSON Schema เมื่อข้อมูลยังไม่ตรง
  5. ใช้ Mock Field หรือ Property Name Matching Rule สำหรับฟิลด์เฉพาะ
  6. ใช้ Mock Expectations เมื่อจำเป็นต้องตอบสนองตามเงื่อนไข

เมื่อ schema เป็นแหล่งข้อมูลเดียว mock จะปรับตาม contract ได้ทันที และทีมฟรอนต์เอนด์ไม่ต้องรอ backend เพื่อเริ่มพัฒนา UI

Top comments (0)