วิธีสร้าง Mock Server บนคลาวด์ที่แชร์ได้ด้วย Apidog

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

นี่คือช่องว่างที่ Apidog ปิดได้ด้วย Cloud Mock แทนที่จะเป็น mock ที่มีอายุสั้นและตายไปพร้อมกับเครื่องเดียว คุณจะได้ URL สาธารณะที่โฮสต์อยู่ที่ mock.apidog.com ซึ่งเปิดใช้งานตลอด 24 ชั่วโมง นักพัฒนาส่วนหน้า, QA, และนักพัฒนาคู่ค้าสามารถเรียกใช้ปลายทางที่สมจริงได้ก่อนที่โค้ดส่วนหลังบ้านแม้แต่บรรทัดเดียวจะถูกเผยแพร่ หากคุณต้องการภาพรวมที่กว้างขึ้นว่าการ mocking มีประโยชน์ต่อทีมอย่างไร บทนำของเราเกี่ยวกับ API mock คืออะไรและเมื่อไหร่ควรใช้ จะช่วยปูพื้นฐาน สำหรับกลไกของ URL mock สาธารณะที่เข้ากับการจัดการคำขอ เอกสารอ้างอิงของ MDN เกี่ยวกับโมเดลคำขอ/การตอบกลับ HTTP เป็นการทบทวนที่ดี

Cloud Mock คืออะไร และทำไม local mocks ถึงมีข้อจำกัด

Apidog สร้างปลายทาง mock สำหรับทุก API ที่คุณออกแบบ โดยค่าเริ่มต้น mock นั้นเป็น mock แบบโลคัล: มันจะทำงานจากอินสแตนซ์ Apidog ของคุณและตอบกลับในขณะที่เครื่องของคุณเปิดอยู่ ทันทีที่คุณปิดเครื่อง ปลายทางก็จะหยุดตอบกลับ นั่นเป็นเรื่องปกติสำหรับการดีบักเดี่ยวๆ แต่จะพังทลายทันทีที่มีคนอื่นขึ้นอยู่กับ URL นั้น

Cloud Mock คือทางออก เป็นปลายทาง mock ที่พร้อมใช้งานอย่างต่อเนื่องซึ่งคงอยู่ได้อย่างอิสระจากเครื่องใดๆ คอมพิวเตอร์ของเพื่อนร่วมทีมของคุณอาจจะหลับอยู่ แล็ปท็อปของคุณอาจจะอยู่ในกระเป๋า แต่ cloud mock ยังคงตอบกลับคำขอตลอด 24 ชั่วโมงทุกวัน ปลายทางนี้อยู่บนบริการโฮสต์ของ Apidog ดังนั้นความพร้อมใช้งานจึงไม่ขึ้นอยู่กับว่าใครกำลังออนไลน์อยู่

ผลตอบแทนที่ใช้งานได้จริงคือการส่งมอบงานที่ราบรื่น คุณออกแบบสัญญา เปิด Cloud Mock และแชร์ URL เดียว ทีมส่วนหน้าจะพัฒนาโดยใช้ข้อมูลที่สมจริง ทีม QA จะเขียนกรณีทดสอบตามรูปแบบการตอบกลับจริง และคู่ค้าที่ทำงานร่วมกับคุณสามารถเริ่มเชื่อมต่อไคลเอนต์ของตนได้ทันที ไม่มีใครต้องรอส่วนหลังบ้าน และไม่มีใครต้องรอให้คุณเปิดโปรเซสทำงาน หากคุณกำลังประสานงานข้ามภูมิภาค รูปแบบใน การแชร์ mock servers และสภาพแวดล้อมกับทีมทั่วโลก จะอธิบายเวิร์กโฟลว์ในรายละเอียดเพิ่มเติม

เปิดใช้งาน Cloud Mock และรับ URL สาธารณะของคุณ

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

ขั้นตอนที่ 1: เปิด Cloud Mock

เปิดโปรเจกต์ของคุณแล้วไปที่ Project Settings > Feature Settings > Mock Settings สลับเปิด Cloud Mock นี่คือสวิตช์ที่บอกให้ Apidog โฮสต์ mocks ของคุณบนบริการที่เปิดใช้งานตลอดเวลา แทนที่จะให้บริการเฉพาะแบบโลคัล

คุณทำสิ่งนี้เพียงครั้งเดียวต่อโปรเจกต์ หลังจากเปิดใช้งานแล้ว ทุกปลายทางในโปรเจกต์จะได้รับ URL ของ cloud mock ควบคู่ไปกับ URL แบบโลคัล

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

เปิดปลายทางที่คุณต้องการแชร์ ในกรณีนี้คือ GET /users ไปที่แท็บ Mock แล้วคัดลอก Cloud Mock URL คุณจะได้ URL ที่มีรูปแบบประมาณนี้:

https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi

โครงสร้างพาธเป็นไปตามรูปแบบ: mock.apidog.com/m1/<projectId>-<num>-<env>/<path> Apidog สร้างให้คุณ ดังนั้นคุณไม่จำเป็นต้องประกอบเอง โปรดทราบว่าเอกสารแสดงสิ่งนี้ด้วยตัวอย่างแทนที่จะเผยแพร่เทมเพลตที่ตายตัว ดังนั้นให้ถือว่า URL ที่คัดลอกมาเป็นแหล่งที่มาของความจริง แทนที่จะพยายามสร้างขึ้นเอง

ขั้นตอนที่ 3: ทดสอบ mock ทันทีภายใน Apidog

ก่อนที่คุณจะส่ง URL ให้ใคร ให้ยืนยันว่ามันคืนค่าที่คุณคาดหวัง ในแท็บ Mock เดียวกัน ให้ส่งคำขอทดสอบไปยัง URL ของ mock Apidog จะยิงคำขอและแสดงการตอบกลับให้คุณเห็นทันที คุณจะทราบได้ทันทีว่าข้อมูลที่สร้างขึ้นถูกต้องหรือไม่

mock สำหรับ GET /users อาจตอบกลับมาแบบนี้:

[
  {
    "id": 1,
    "name": "Amelia Turner",
    "email": "amelia.turner@example.com",
    "city": "Portland"
  },
  {
    "id": 2,
    "name": "Marcus Bell",
    "email": "marcus.bell@example.com",
    "city": "Austin"
  }
]

ค่าเหล่านั้นไม่ได้ถูกฮาร์ดโค้ด Apidog อ่านชื่อฟิลด์และประเภทของสกีมาของคุณ และสร้างข้อมูลที่เป็นไปได้เพื่อให้ตรงกัน ซึ่งเป็นสิ่งที่ทำให้ mock มีประโยชน์สำหรับส่วนหน้าในการแสดงผลตารางที่ดูสมจริง

ขั้นตอนที่ 4: เปิด URL ในเบราว์เซอร์

สำหรับคำขอ GET, URL ของ cloud mock สามารถใช้ได้โดยตรงในเว็บเบราว์เซอร์ วางลงในแถบที่อยู่ แล้วคุณจะเห็นการตอบกลับในรูปแบบ JSON นี่คือการตรวจสอบความถูกต้องที่รวดเร็วที่สุดที่คุณสามารถส่งให้ผู้ที่ไม่ใช่สายเทคนิคได้: ไม่ต้องมีไคลเอนต์, ไม่ต้องใช้ curl, มีเพียงลิงก์ที่ส่งคืนข้อมูล

สำหรับสิ่งอื่นนอกเหนือจากการดูอย่างรวดเร็ว ส่วนหน้าของคุณจะเรียกใช้เหมือนปลายทางอื่น ๆ:

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"

นั่นคือขั้นตอนทั้งหมด ออกแบบปลายทาง เปิดใช้งาน Cloud Mock คัดลอก URL และทีมของคุณก็จะทำงานต่อได้โดยไม่ติดขัด

ล็อก mock ด้วยการยืนยันตัวตนด้วยโทเค็น

URL สาธารณะนั้นสะดวก และบางครั้งก็สะดวกเกินไป หาก mock ของคุณสะท้อนถึงฟีเจอร์ที่ยังไม่เผยแพร่หรือการเชื่อมต่อกับพันธมิตรที่คุณไม่ต้องการเปิดเผย คุณสามารถตั้งค่าการเข้าถึงได้

ไปที่ Project Settings > Feature Settings > Mock Settings และตั้งค่าการอนุญาตการเข้าถึงเป็น Token Authentication เมื่อเปิดใช้งานแล้ว ทุกคำขอจะต้องมี apidogToken ที่ถูกต้อง และคำขอที่ไม่มีโทเค็นจะถูกปฏิเสธ คุณสามารถระบุโทเค็นได้สามวิธี:

ในฐานะพารามิเตอร์ query-string ของ URL ซึ่งเป็นสิ่งที่ URL ที่คัดลอกมาใช้แล้ว:

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"

ในฐานะเฮดเดอร์คำขอ ซึ่งจะเก็บโทเค็นออกจาก URL และออกจากบันทึกเซิร์ฟเวอร์:

curl "https://mock.apidog.com/m1/2689726-0-default/users" \
  -H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"

หรือเป็นพารามิเตอร์ในส่วนเนื้อหาชื่อ apidogToken ในคำขอ form-data หรือ x-www-form-urlencoded ซึ่งเหมาะสำหรับไคลเอนต์ที่โพสต์ข้อมูลแบบฟอร์ม

สำหรับโค้ดส่วนหน้า วิธีการใช้เฮดเดอร์มักจะสะอาดที่สุด มันช่วยเก็บโทเค็นออกจากสิ่งใดๆ ที่บันทึก URL แบบเต็ม และแยกข้อมูลประจำตัวออกจากพาธของทรัพยากร:

const res = await fetch(
  "https://mock.apidog.com/m1/2689726-0-default/users",
  { headers: { apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi" } }
);
const users = await res.json();

สิ่งหนึ่งที่ต้องวางแผนไว้: หากคุณเปิดใช้งาน Token Authentication หลังจากที่แชร์ URL แบบธรรมดาไปแล้ว ผู้ใช้งานทุกคนจะต้องเพิ่มโทเค็น มิฉะนั้นการเรียกใช้ของพวกเขาจะเริ่มล้มเหลว ประสานงานการเปลี่ยนแปลงนี้เพื่อให้ QA และคู่ค้าไม่ติดอยู่กับคำขอที่ถูกปฏิเสธ

สร้างข้อมูลที่สมจริงและคำนึงถึงภูมิภาคด้วย locales

mock ที่ส่งคืน "name": "string" สำหรับทุกรายการไม่ได้สอนอะไร UI ของคุณเลย mock ที่ส่งคืนชื่อ ที่อยู่ และหมายเลขโทรศัพท์ที่ดูสมจริงจะช่วยให้ส่วนหน้าตรวจจับข้อบกพร่องในการจัดวาง, ข้อความล้น และปัญหาการจัดรูปแบบได้ก่อนที่ข้อมูลจริงจะมาถึง Apidog จัดการสิ่งนี้ด้วย Faker.js ภายใต้เบื้องหลัง และการควบคุม locale คือส่วนที่ทำให้มันมีประโยชน์อย่างแท้จริงสำหรับผลิตภัณฑ์ระหว่างประเทศ

Locale เริ่มต้นทำงานอย่างไร

โดยค่าเริ่มต้น Faker จะปฏิบัติตามการตั้งค่าภาษาของโปรเจกต์ของคุณ สิ่งนี้ถูกกำหนดค่าใน Project Settings > Basic Settings และภาษาใดก็ตามที่คุณเลือกที่นั่นจะกลายเป็น locale เริ่มต้นสำหรับค่า mock ที่สร้างขึ้นทั้งหมด ตั้งค่าโปรเจกต์เป็นภาษาฝรั่งเศส แล้วชื่อและที่อยู่ของ mock ของคุณจะถูกส่งกลับมาเป็นแบบฝรั่งเศสโดยไม่ต้องทำงานกับแต่ละฟิลด์

กำหนด locale ทับทั้งโปรเจกต์

หากคุณต้องการข้อมูล mock ใน locale เฉพาะที่แตกต่างจากภาษาของโปรเจกต์ คุณสามารถกำหนดทับได้ ไปที่ Project Settings > Feature Settings > Mock Settings และเลือก Faker locale จากรายการดรอปดาวน์ การกำหนดทับนี้จะใช้แทนค่าเริ่มต้นของภาษาใน Basic Settings สำหรับทุกฟิลด์ในโปรเจกต์

สิ่งนี้มีประโยชน์เมื่อคุณกำลังทดสอบการทำให้เป็นสากล กำหนด locale ของโปรเจกต์ไปที่ญี่ปุ่น แล้วที่อยู่ ชื่อ และหมายเลขโทรศัพท์ที่สร้างขึ้นทั้งหมดจะสะท้อนถึงภูมิภาคนั้น ดังนั้นคุณจะเห็นว่า UI ของคุณทำงานได้ดีแค่ไหนกับสคริปต์ที่ไม่ใช่ภาษาละตินและรูปแบบที่อยู่ต่างๆ การสร้างข้อมูลที่เข้าใจสกีมาแบบอัตโนมัตินี้เป็นหัวข้อหนึ่งในตัวมันเอง และคำอธิบายเชิงลึกเกี่ยวกับ Smart mock ของ Apidog และวิธีที่มันอ่านสกีมาของคุณ จะครอบคลุมด้านการสร้างข้อมูลอย่างละเอียด

กำหนด locale ทับทีละฟิลด์

บางครั้งคุณอาจต้องการให้ฟิลด์หนึ่งมี locale ที่แตกต่างจากส่วนที่เหลือ เช่น รายชื่อลูกค้าที่มาจากหลายภูมิภาค คุณสามารถตั้งค่า locale ได้โดยตรงในนิพจน์ mock โดยใช้ `locale parameter`:

{{$person.fullName(locale='ja')}}

สิ่งนี้จะส่งออกชื่อภาษาญี่ปุ่น เช่น 田中 太郎 สำหรับฟิลด์นั้นเท่านั้น ในขณะที่ส่วนที่เหลือของการตอบกลับจะปฏิบัติตาม locale ของโปรเจกต์ ลำดับความสำคัญมีสามระดับ: locale ระดับฟิลด์จะแทนที่ locale ระดับโปรเจกต์ ซึ่งจะแทนที่ค่าเริ่มต้นของภาษาใน Basic Settings ดังนั้นคุณจึงกำหนดค่าเริ่มต้นของโปรเจกต์ที่เหมาะสม และใช้การกำหนดทับระดับฟิลด์เฉพาะในกรณีที่คุณต้องการข้อยกเว้นจริงๆ

ข้อสังเกตสั้นๆ เกี่ยวกับขอบเขต: เอกสารแสดง ja เป็นตัวอย่างที่ใช้งานได้จริงและไม่ได้เผยแพร่รายการ locales ที่รองรับทั้งหมด ดังนั้นโปรดยืนยันรหัสที่ถูกต้องสำหรับภูมิภาคเป้าหมายของคุณใน เอกสารประกอบ mock ของ Apidog ก่อนที่คุณจะใช้งานมัน หลักการของ Faker เองมีการบันทึกไว้ใน เอกสารอ้างอิง locale ของ Faker.js

จับคู่เขตเวลาด้วย

มีการควบคุมคู่ขนานสำหรับเวลา ค่าเริ่มต้นระดับโปรเจกต์อยู่ใน Project Settings > Feature Settings > Mock Settings และคุณสามารถกำหนดทับได้ต่อฟิลด์ด้วย `timeZone parameter` ภายในนิพจน์ mock หาก UI ของคุณแสดงการประทับเวลา สิ่งนี้จะช่วยให้ค่า createdAt ที่สร้างขึ้นสอดคล้องกับภูมิภาคที่คุณกำลังจำลอง แทนที่จะใช้ค่าเริ่มต้นตามที่เซิร์ฟเวอร์ของคุณตั้งอยู่

ระหว่างการควบคุม locale และเขตเวลา คุณสามารถสร้าง mock ที่เลียนแบบฐานผู้ใช้ชาวญี่ปุ่น ชาวเยอรมัน หรือกลุ่มผู้ใช้จากนานาชาติได้อย่างน่าเชื่อถือ ทั้งหมดนี้จากสกีมาปลายทางเดียวกัน สำหรับชุดสถานการณ์ที่กว้างขึ้นที่สิ่งนี้ปลดล็อก การรวบรวม กรณีการใช้งานจริงของ API mocking ก็ควรค่าแก่การพิจารณา

Cloud Mock เทียบกับ self-hosted mock

Cloud Mock เป็นตัวเลือกที่ Apidog โฮสต์ให้ และครอบคลุมทีมส่วนใหญ่ หากองค์กรของคุณมีกฎการเก็บข้อมูลหรือนโยบายที่ต่อต้านการส่งทราฟฟิกทดสอบผ่านคลาวด์ของผู้จำหน่าย Apidog ก็รองรับการเรียกใช้บริการ mock บนโครงสร้างพื้นฐานของคุณเองด้วย ข้อแลกเปลี่ยนนั้นตรงไปตรงมา: ตัวเลือกคลาวด์คือการติดตั้งแบบศูนย์และเปิดใช้งานตลอดเวลา ในขณะที่การโฮสต์เองให้คุณควบคุมได้โดยมีค่าใช้จ่ายในการเรียกใช้บริการด้วยตัวเอง หากนี่คือสถานการณ์ของคุณ คู่มือ การโฮสต์ Apidog mock server ด้วยตัวเอง จะอธิบายขั้นตอน สำหรับทีมที่กำลังพิจารณาตัวเลือกการโฮสต์แบบคู่ขนาน การเปรียบเทียบเครื่องมือ API mocking ออนไลน์ จะแสดงภาพรวม

เกี่ยวกับการจำกัดแผนงาน คำตอบตรงๆ คือ: คุณสมบัติ Cloud Mock และ locale ที่ระบุไว้ในเอกสารนี้ไม่ได้ระบุข้อกำหนดแผนงานที่เฉพาะเจาะจง ดังนั้นวิธีที่ซื่อสัตย์ที่สุดคือการตรวจสอบความพร้อมใช้งานปัจจุบันในบัญชีของคุณเอง แทนที่จะยึดตามตัวเลขจากบล็อกโพสต์ คุณสามารถ ดาวน์โหลด Apidog และทดลองใช้งานตั้งแต่ต้นจนจบเพื่อดูว่าพื้นที่ทำงานของคุณมีอะไรบ้าง

ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI

การ mocking ใน Apidog เป็นความสามารถของ GUI และคลาวด์ การตอบกลับของ mock ถูกสร้างขึ้นโดยอัตโนมัติจากสกีมาปลายทางของคุณ และให้บริการโดยเอนจินที่ Apidog โฮสต์ ไม่ใช่โดยสิ่งที่คุณเรียกใช้ในเทอร์มินัล ดังนั้นการอธิบายอย่างตรงไปตรงมาคือ: Apidog CLI ไม่ได้เริ่มต้นหรือให้บริการ mock server สิ่งที่มันทำคือรักษาข้อมูลที่ป้อนเข้า mock ของคุณให้ถูกต้อง

CLI และตัวแทนเขียนโค้ด AI เช่น Cursor หรือ Claude Code สามารถสร้างและอัปเดตปลายทางและสกีมาในโปรเจกต์ของคุณได้ เนื่องจากการ mock บนคลาวด์อ่านสกีมาเหล่านั้นเพื่อสร้างข้อมูล การรักษาสเปคให้เป็นปัจจุบันจะช่วยให้ผลลัพธ์ของ mock ถูกต้องเมื่อ API พัฒนาไป เมื่อคุณใช้เครื่องมืออัตโนมัติเพื่อเพิ่มฟิลด์ mock จะสะท้อนการเปลี่ยนแปลงนั้นโดยไม่ต้องแก้ไขด้วยตนเอง

จากนั้น เมื่อ mock ได้ปลดบล็อกงานส่วนหน้าและส่วนหลังบ้านจริงทำงานได้แล้ว สถานการณ์การทดสอบของโปรเจกต์เดียวกันจะทำงานแบบ headless เพื่อทดสอบส่วนหลังบ้าน คำสั่งการเรียกใช้ของ CLI จะตรวจสอบส่วนหลังบ้านที่ทำงานอยู่กับสัญญาเดียวกับที่ mock อธิบายไว้:

apidog run -t <scenario_id> -e <env_id> -r cli

คำสั่งเดียวนี้จะเรียกใช้สถานการณ์การทดสอบที่บันทึกไว้กับสภาพแวดล้อมและรายงานผลลัพธ์ ดังนั้น mock ที่ปลดบล็อก UI และการทดสอบที่ตรวจสอบส่วนหลังบ้านต่างก็อ้างอิงถึงแหล่งความจริงเดียวกัน เปิดสถานการณ์ของคุณใน Apidog และคัดลอกคำสั่งที่สร้างขึ้นโดยมี -t scenario ID และ -e environment ID ที่กรอกไว้แล้ว แทนที่จะประกอบแฟล็กด้วยตนเอง การเชื่อมต่อสิ่งนั้นเข้ากับไปป์ไลน์มีอธิบายไว้ในคู่มือ การเรียกใช้ Apidog ใน CI/CD pipeline

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

URL ของ cloud mock ยังคงทำงานอยู่หรือไม่เมื่อฉันปิด Apidog?

ใช่ นั่นคือจุดประสงค์ทั้งหมดของ Cloud Mock แตกต่างจาก local mock ที่หยุดตอบสนองเมื่อเครื่องโฮสต์ปิดตัวลง cloud mock ให้บริการจากโครงสร้างพื้นฐานของ Apidog และพร้อมใช้งานตลอด 24 ชั่วโมงทุกวัน เพื่อนร่วมทีมของคุณสามารถเรียกใช้ได้ไม่ว่าคอมพิวเตอร์ของคุณจะเปิดอยู่หรือไม่ก็ตาม

ฉันสามารถใช้ URL ของ cloud mock โดยตรงในเบราว์เซอร์ได้หรือไม่?

สำหรับคำขอ GET ทำได้ วาง URL เต็ม รวมถึงพารามิเตอร์คิวรี apidogToken ลงในแถบที่อยู่ของคุณ แล้วคุณจะเห็นการตอบกลับในรูปแบบ JSON สำหรับเมธอดอื่น ๆ หรือเพื่อเก็บโทเค็นออกจากประวัติ URL ของคุณ ให้เรียกใช้ด้วยเครื่องมืออย่าง curl หรือไคลเอนต์ส่วนหน้าของคุณ และส่งโทเค็นเป็นเฮดเดอร์แทน

เกิดอะไรขึ้นกับคำขอที่ไม่มีโทเค็น?

หากคุณได้ตั้งค่าการอนุญาตการเข้าถึงเป็น Token Authentication คำขอใดๆ ที่ไม่มี apidogToken ที่ถูกต้องจะถูกปฏิเสธ ระบุโทเค็นเป็นพารามิเตอร์ query-string, เฮดเดอร์คำขอ, หรือพารามิเตอร์ในส่วนเนื้อหาในคำขอแบบฟอร์ม หากคุณเปิดใช้งานการยืนยันตัวตนด้วยโทเค็นหลังจากแชร์ URL แบบธรรมดาไปแล้ว ให้แจ้งผู้ใช้งานของคุณเพื่อให้พวกเขาสามารถเพิ่มโทเค็นได้ก่อนที่การเรียกใช้ของพวกเขาจะเริ่มล้มเหลว

ฉันจะรับข้อมูล mock ที่ตรงกับประเทศใดประเทศหนึ่งได้อย่างไร?

ตั้งค่า locale ของโปรเจกต์ของคุณใน Basic Settings หรือกำหนดทับทั้งโปรเจกต์ภายใต้ Feature Settings > Mock Settings หรือกำหนดทับฟิลด์เดียวด้วยพารามิเตอร์ locale ในนิพจน์ mock เช่น {{$person.fullName(locale='ja')}} การตั้งค่าระดับฟิลด์จะสำคัญกว่าระดับโปรเจกต์ ซึ่งสำคัญกว่าค่าเริ่มต้นของ Basic Settings คำแนะนำการใช้งาน smart mock แสดงให้เห็นว่าการสร้างข้อมูลที่เข้าใจสกีมามีความเชื่อมโยงกับสิ่งนี้อย่างไร

ฉันควรใช้ Cloud Mock หรือเครื่องมือ headless mock?

Cloud Mock เหมาะสำหรับทีมที่ต้องการปลายทางที่โฮสต์และไม่ต้องบำรุงรักษา ซึ่งเชื่อมโยงกับการออกแบบ API ของพวกเขา หากคุณต้องการ mocks ที่ฝังอยู่ในการสร้างอัตโนมัติโดยไม่มี GUI เลย การสำรวจ เครื่องมือ headless mock จะเปรียบเทียบตัวเลือกและตำแหน่งที่แต่ละตัวเหมาะสม ข้อกำหนดของ OpenAPI Initiative เป็นรากฐานของเครื่องมือส่วนใหญ่เหล่านี้ ดังนั้นสเปคที่ชัดเจนจะให้ผลตอบแทนไม่ว่าคุณจะเลือกเส้นทางใด

สรุป

mock ที่มีอยู่บนแล็ปท็อปของคุณเท่านั้นจะช่วยให้คนเพียงคนเดียวทำงานต่อได้ Cloud Mock เปลี่ยนมันให้เป็น URL สาธารณะ mock.apidog.com ที่ทั้งทีมของคุณสามารถใช้พัฒนาได้ พร้อมการยืนยันตัวตนด้วยโทเค็นเมื่อคุณต้องการจำกัดการเข้าถึง และการควบคุม locale เมื่อข้อมูลของคุณต้องการดูสมจริงสำหรับภูมิภาคเฉพาะ ออกแบบปลายทาง สลับสวิตช์ แชร์ลิงก์ แล้วส่วนหน้าก็ไม่ต้องรอส่วนหลังบ้านอีกต่อไป ดาวน์โหลด Apidog เพื่อตั้งค่า cloud mock ที่สามารถแชร์ได้ครั้งแรกของคุณ ฟรีและไม่ต้องใช้บัตรเครดิต