Cara Mock API di Apidog Tanpa Coding

Tim frontend sering terhambat ketika backend untuk GET /users dan GET /orders belum siap. UI tetap membutuhkan data realistis untuk merender daftar, paginasi, serta status kosong. Menulis file JSON palsu secara manual memang bisa dilakukan, tetapi file tersebut cepat tidak sinkron saat kontrak API berubah. Jika spesifikasi API sudah tersedia, Apidog dapat membuat mock langsung dari skema endpoint melalui Smart Mock—tanpa konfigurasi tambahan dan tanpa menulis server mock sendiri.

Coba Apidog hari ini

Smart Mock membaca nama dan tipe properti untuk menghasilkan data yang relevan. Misalnya, name dapat menghasilkan nama, sedangkan email menghasilkan alamat email. Artikel ini menunjukkan cara memock endpoint e-commerce, memilih URL mock, memahami prioritas respons, dan mengoreksi output Smart Mock bila diperlukan. Untuk konteks dasar, baca apa itu mocking API dan bagaimana cara kerjanya serta dokumentasi JSON Schema.

Apa yang dilakukan Smart Mock

Mesin mock Apidog mendukung beberapa pendekatan respons:

1. Smart Mock: menghasilkan data otomatis dari skema API.
2. Contoh Respons: mengembalikan example yang Anda definisikan.
3. Custom Mock: mengembalikan respons kustom.
4. Mock Expectation: mengembalikan respons berdasarkan parameter atau kondisi request.
5. Mock Script: menghasilkan respons yang nilainya terkait dengan request.

Smart Mock adalah opsi fallback tanpa konfigurasi di Apidog. Selama endpoint memiliki skema respons, Smart Mock dapat mengisi setiap properti dengan data yang sesuai.

Praktiknya:

• Import atau desain API satu kali.
• Definisikan respons dan skemanya.
• Endpoint langsung dapat dipanggil sebagai mock.
• Saat skema berubah, output mock ikut berubah karena menggunakan sumber kontrak yang sama.

Prasyarat

Smart Mock membutuhkan definisi respons pada endpoint.

Jika Anda mendesain API di Apidog, tambahkan schema pada bagian response endpoint. Jika mengimpor OpenAPI, schema respons biasanya sudah ikut terbawa.

Untuk menggunakan Local Mock, gunakan aplikasi desktop Apidog karena fitur ini berjalan di komputer lokal dan tidak tersedia di Apidog Web. Unduh Apidog untuk mengikuti langkah berikut.

Langkah demi langkah: mock GET /users dan GET /orders

1. Definisikan endpoint dan schema respons

Buat endpoint GET /users dengan contoh respons berikut:

{
  "id": 1024,
  "name": "Amara Osei",
  "email": "[e-mail]",
  "phone": "[phone]",
  "createdAt": "2026-03-11T09:24:00Z",
  "isActive": true
}

Buat juga endpoint GET /orders yang mengembalikan array:

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

Pastikan setiap properti memiliki tipe yang jelas di schema. Smart Mock menggunakan tipe dan nama properti untuk menentukan data yang dihasilkan.

2. Salin URL mock

Setiap endpoint mendapatkan URL mock secara otomatis.

• Pada mode DESIGN, buka tab API di bawah endpoint.
• Pada mode DEBUG, buka tab Mock.

Klik Klik untuk menyalin untuk mengambil URL mock. Tombol ini hanya menyalin URL; Anda tetap harus menentukan HTTP method dan request body saat endpoint memerlukannya.

Dalam mode path, URL Local Mock berbentuk:

http://127.0.0.1:4523/m1/{projectID}-{versionNo}-{serverNo}/users

Local Mock berjalan otomatis ketika aplikasi Apidog terbuka. Anda juga dapat menggunakan mode ID:

http://127.0.0.1:4523/m2/{projectID}-{versionNo}-{serverNo}/{endpointId}

3. Panggil endpoint mock

Panggil endpoint users menggunakan curl:

curl http://127.0.0.1:4523/m1/1234567-0-0/users

Contoh hasilnya:

{
  "id": 3187,
  "name": "Diego Marchetti",
  "email": "[e-mail]",
  "phone": "[phone]",
  "createdAt": "2026-01-27T18:41:22Z",
  "isActive": true
}

Nilai name dan email bukan sekadar string acak. Smart Mock menggunakan Property Name Matching untuk mengenali arti nama properti.

Panggil orders dengan cara yang sama:

curl http://127.0.0.1:4523/m1/1234567-0-0/orders

Responsnya berupa array order dengan total, status, dan timestamp yang dapat langsung dipakai untuk mengembangkan tampilan daftar pesanan.

Cara Smart Mock menentukan nilai

Smart Mock menggunakan tiga tingkat prioritas saat mengisi properti.

1. Mock Field Jika properti memiliki nilai atau ekspresi kustom, nilai tersebut digunakan terlebih dahulu.

Gunakan:

• Fixed value untuk nilai statis.
• Faker statement untuk data dinamis.

Contohnya, status dapat dikonfigurasi agar menghasilkan shipped, pending, atau delivered.

1. Property Name Matching Jika Mock Field belum diatur, Smart Mock mencocokkan nama properti dengan aturan bawaan menggunakan wildcard atau regular expression.

Ini menjelaskan mengapa properti seperti email dan createdAt dapat menghasilkan nilai yang relevan.

1. JSON Schema Jika nama properti tidak cocok dengan aturan apa pun, Smart Mock menggunakan tipe dan batasan schema sebagai fallback.

Output Smart Mock mengikuti batasan JSON Schema, termasuk:

• panjang string;
• nilai enum;
• minimum dan maximum untuk angka;
• minItems dan panjang array;
• pola (pattern) untuk string.

Contoh schema yang lebih ketat:

{
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "enum": ["pending", "shipped", "delivered"]
    },
    "total": {
      "type": "number",
      "minimum": 1,
      "maximum": 1000
    },
    "sku": {
      "type": "string",
      "pattern": "^SKU-[0-9]{6}$"
    }
  }
}

Dengan schema tersebut, status hanya akan memakai salah satu nilai enum, total berada dalam rentang yang ditentukan, dan sku mengikuti pola yang diberikan.

Apidog juga mendukung locale mock untuk menghasilkan data dalam format regional tertentu, seperti nama dan alamat yang sesuai dengan pasar target.

Memperbaiki output Smart Mock yang tidak sesuai

Smart Mock berbasis inferensi. Properti seperti sku atau total mungkin tidak selalu mendapatkan output yang diinginkan tanpa batasan tambahan.

Gunakan pendekatan berikut, dari yang paling sederhana.

Perketat JSON Schema

Tambahkan batasan ke schema sebelum membuat aturan kustom.

• Tambahkan enum untuk status.
• Tambahkan minimum dan maximum untuk total.
• Tambahkan pattern untuk sku.

Contoh:

{
  "total": {
    "type": "number",
    "minimum": 10,
    "maximum": 999.99
  }
}

Atur Mock Field

Gunakan Mock Field jika schema saja belum cukup.

Contoh penggunaan:

• Atur currency sebagai Fixed value: USD.
• Atur status dengan Faker statement untuk menghasilkan variasi nilai yang valid.

Lapisan Faker Apidog memiliki konsep yang serupa dengan Mock.js. Untuk sintaks lebih lanjut, baca panduan penggunaan Faker di Apidog.

Tambahkan aturan Property Name Matching

Jika properti yang sama muncul di banyak endpoint, tambahkan aturan global agar tidak perlu mengatur Mock Field satu per satu.

Buka:

Settings
→ General Settings
→ Feature Settings
→ Mock Settings
→ New

Kemudian:

1. Buat kondisi yang mencocokkan nama properti, misalnya sku.
2. Tentukan ekspresi mock yang sesuai.
3. Simpan aturan.

Setelah itu, setiap properti sku dalam proyek dapat menghasilkan pola yang sama alih-alih string generik.

Prioritas respons mock

Ketika endpoint memiliki beberapa kemungkinan sumber respons, Apidog menggunakan pengaturan Default mock method pada:

Project Settings
→ Mock Settings

Tersedia dua pilihan:

• Smart Mock First
  
  Urutan: Mock Expectation → Smart Mock

• Response Example First
  
  Urutan: Mock Expectation → Response Example → Smart Mock

Mock Expectation selalu memiliki prioritas tertinggi ketika kondisinya cocok.

Misalnya, Anda dapat membuat expectation yang mengembalikan 404 jika userId=9999. Respons ini akan digunakan terlebih dahulu, terlepas dari metode mock default yang dipilih.

Untuk implementasi respons berbasis kondisi, lihat panduan mocking respons API kondisional di Apidog.

Ringkasnya:

Mock Expectation
→ Response Example atau Smart Mock
→ fallback sesuai pengaturan proyek

Local Mock, Cloud Mock, dan Runner Mock

Cara respons dibuat dan tempat mock dijalankan adalah dua hal berbeda.

Local Mock

Local Mock berjalan di komputer Anda melalui aplikasi Apidog.

• Aktif saat aplikasi Apidog terbuka.
• Mendengarkan pada 127.0.0.1:4523.
• Cocok untuk pengembangan frontend lokal.
• Tidak tersedia di Apidog Web.

Cloud Mock

Cloud Mock di-host pada server Apidog.

• Dapat dijangkau 24/7.
• Perlu diaktifkan melalui manajemen environment.
• Menggunakan domain https://mock.apidog.com.
• Cocok untuk kolaborasi tim atau preview yang di-deploy.
• Ditujukan untuk testing, bukan traffic produksi.

Runner Mock

Runner Mock dijalankan sendiri pada infrastruktur tim.

• Cocok untuk jaringan internal.
• Memungkinkan mock tetap berada di lingkungan server Anda sendiri.
• Dapat dibagikan ke seluruh tim.

Gunakan:

• Local Mock untuk pekerjaan frontend individual.
• Cloud Mock saat rekan tim atau environment preview perlu mengakses mock.
• Runner Mock saat mock harus tetap berada di infrastruktur internal.

Bandingkan opsi yang tersedia melalui perbandingan alat mocking API online atau ikuti panduan Apidog Cloud Mock.

Jebakan routing yang perlu diperhatikan

Path harus dimulai dengan /

Gunakan path endpoint seperti ini:

/orders

Path lengkap tanpa awalan / tidak akan menggunakan environment mock. Path tanpa slash awal hanya bekerja dalam mode ID.

Endpoint dengan method dan path yang sama

Jika dua endpoint memiliki HTTP method dan path yang sama, mode path tidak dapat membedakannya secara otomatis.

Tambahkan parameter berikut untuk memilih endpoint yang benar:

?apidogApiId={endpointId}

Data berubah saat request diulang

Smart Mock dapat menghasilkan ulang nilai dinamis saat request disegarkan. Jika respons tampak sama terus, pastikan Anda tidak membaca hasil yang tersimpan di cache dan benar-benar mengirim request baru.

Otomatiskan workflow dengan Apidog CLI

Apidog CLI tidak menjalankan atau meng-host server mock dari terminal. Local Mock, Cloud Mock, dan Runner Mock tetap menjadi mekanisme untuk menyajikan respons mock.

CLI membantu menjaga schema API—yang menjadi dasar Smart Mock—tetap akurat ketika proyek berkembang. Karena output Smart Mock dihasilkan dari schema endpoint, perubahan kontrak API perlu diperbarui pada sumber yang sama.

Apidog CLI dapat digunakan dalam workflow CI untuk menjalankan skenario pengujian terhadap backend nyata:

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

Instal CLI:

npm install -g apidog-cli

Autentikasi dengan token:

apidog login --with-token <token-anda>

CLI membutuhkan Node.js v16 atau yang lebih baru. Lihat panduan instalasi Apidog CLI dan panduan menjalankan Apidog dalam pipeline CI/CD.

FAQ

Apakah Smart Mock membutuhkan kode?

Tidak. Selama endpoint memiliki schema respons, Smart Mock dapat menghasilkan data otomatis. Kode, Faker statement, atau mock script hanya diperlukan saat Anda ingin mengontrol output tertentu.

Baca ikhtisar API mock untuk konsep dasarnya.

Mengapa URL mock tidak mengembalikan respons?

Periksa hal berikut:

1. Endpoint memiliki definisi respons dan schema.
2. Path endpoint dimulai dengan /.
3. Aplikasi Apidog terbuka jika menggunakan Local Mock.
4. URL mock dan environment yang digunakan sudah benar.

Bagaimana cara mengembalikan nilai tetap?

Atur Mock Field pada properti tersebut.

• Gunakan Fixed value untuk nilai yang selalu sama.
• Gunakan Faker statement untuk nilai dinamis tetapi terkontrol.

Mock Field memiliki prioritas lebih tinggi daripada Property Name Matching dan fallback JSON Schema.

Bisakah rekan tim mengakses Local Mock di laptop saya?

Hanya melalui jaringan lokal dan selama aplikasi Apidog terbuka. Local Mock mendengarkan pada 127.0.0.1:4523.

Untuk akses yang selalu tersedia, aktifkan Cloud Mock melalui https://mock.apidog.com.

Respons mana yang dipakai jika ada Response Example dan Smart Mock?

Tergantung pada pengaturan default mock method:

• Smart Mock First: Smart Mock digunakan setelah Mock Expectation.
• Response Example First: Response Example digunakan sebelum Smart Mock.
• Mock Expectation: selalu menang jika kondisinya cocok.

Ringkasan

Smart Mock mengubah schema API menjadi endpoint mock yang dapat langsung dipanggil tanpa menulis server atau data palsu secara manual.

Workflow praktisnya:

1. Definisikan response dan schema endpoint.
2. Salin URL mock dari tab API atau Mock.
3. Panggil endpoint dari frontend.
4. Perketat schema jika output belum sesuai.
5. Gunakan Mock Field atau Property Name Matching untuk kontrol tambahan.
6. Gunakan Mock Expectation untuk respons kondisional.

Dengan pendekatan ini, frontend dapat tetap berjalan sebelum backend siap, sementara mock dan kontrak API tetap berasal dari sumber yang sama.