Apa Itu Mocky dan Alternatif Mocky Terbaik untuk Respons HTTP Mock Kustom

Jika Anda pernah membutuhkan *endpoint* API palsu yang mengembalikan *body* JSON, kode status, dan *header* tertentu tanpa harus menyiapkan *server*, Anda mungkin pernah mencari Mocky. Panduan ini menjelaskan apa itu Mocky, cara menggunakannya, dan kapan Anda akan melampaui kebutuhannya. Jika Anda ingin gambaran umum yang lebih luas terlebih dahulu, rangkuman kami tentang perbandingan alat *mocking* API *online* mencakup bidang ini, dan *repository open-source* Mocky sendiri mengkonfirmasi dasar-dasarnya.

tombol

Apa itu Mocky?

Mocky adalah layanan web *open-source* gratis untuk menghasilkan respons HTTP kustom. Anda mendesain respons di *browser* Anda, Mocky memberi Anda URL unik, dan setiap permintaan ke URL tersebut mengembalikan persis seperti yang Anda definisikan. Tidak ada *backend* untuk ditulis dan tidak ada *server* untuk di-*hosting*.

Ini dibangun oleh Julien Lafont dan dirilis di bawah lisensi Apache 2.0. Versi yang di-*hosting* berada di mocky.io, dan karena kodenya bersifat publik, Anda juga bisa melakukan *self-host* jika Anda lebih suka menjalankan *instance* Anda sendiri.

Ide intinya sederhana. Anda sedang "mendesain respons di balik URL." Itulah keseluruhan produknya, dan fokus tersebut adalah kekuatan terbesarnya.

Apa yang bisa Anda konfigurasikan

Mocky memungkinkan Anda mengatur bagian-bagian dari respons HTTP yang penting untuk pengujian klien:

Kode status, sehingga Anda dapat mengembalikan 200, 404, atau 500 sesuai permintaan.
*Body* respons, biasanya JSON, tetapi *payload* teks apa pun berfungsi.
*Header* HTTP, termasuk tipe konten dan *header* kustom.
Penundaan respons, sehingga Anda dapat mensimulasikan jaringan lambat atau *upstream* yang lamban.

Setelah Anda menyimpan, Mocky menyimpan respons dan memberi Anda URL permanen. Anda menempelkan URL itu ke kode *front-end* Anda, pengujian Anda, atau klien HTTP Anda, dan Anda selesai.

Contoh singkat

Misalnya *back-end* Anda belum siap, tetapi *front-end* Anda membutuhkan objek pengguna untuk dirender. Anda akan membuka desainer Mocky, mengatur status ke 200, mengatur Content-Type: application/json, dan menempelkan *body* seperti ini:

{
  "id": 42,
  "name": "Ada Lovelace",
  "role": "admin"
}

Mocky mengembalikan URL seperti https://run.mocky.io/v3/<some-id>. Arahkan aplikasi Anda ke sana, dan setiap permintaan akan mendapatkan pengguna tersebut kembali. Untuk gambaran yang lebih luas tentang pola ini, lihat penjelasan kami tentang cara *mock* API *online* tanpa menyiapkan *server*.

Kapan Mocky adalah Pilihan yang Tepat

Mocky bersinar ketika kebutuhan Anda kecil dan bersifat *one-off*:

Anda menginginkan satu respons statis yang cepat, tanpa akun.
Anda berbagi *payload* tetap dengan rekan tim atau tiket dukungan.
Anda mereproduksi satu kasus kesalahan, seperti respons kesalahan *server internal* 500, untuk laporan *bug*.
Anda tidak memerlukan respons yang berubah berdasarkan permintaan.

Untuk pekerjaan-pekerjaan ini, Mocky sulit dikalahkan. Ini gratis, dapat dimuat di *browser*, dan Anda bisa mendapatkan URL yang berfungsi dalam waktu kurang dari satu menit. Jangan terlalu merancang solusi untuk masalah sekecil ini.

Di Mana Mocky Mulai Menyulitkan

Kesederhanaan yang sama yang membuat Mocky hebat juga membatasinya. Setiap URL Mocky adalah satu respons tetap. Seiring pertumbuhan proyek Anda, model itu menjadi kurang memadai dalam beberapa cara yang dapat diprediksi.

Tidak ada data dinamis. Setiap pemanggil mendapatkan *body* yang identik. Anda tidak dapat mengembalikan pengguna yang berbeda untuk /users/1 versus /users/2, dan Anda tidak dapat menghasilkan data yang realistis dan bervariasi.
Tidak ada pencocokan permintaan. Mocky tidak bercabang berdasarkan *query params*, nilai *path*, atau *body* permintaan. Satu URL, satu jawaban.
Organisasi yang longgar. API sungguhan memiliki puluhan *endpoint*. Mengelolanya sebagai tumpukan tautan Mocky terpisah menjadi berantakan dengan cepat.
Kolaborasi yang minim. Tidak ada ruang kerja bersama, tidak ada *versioning*, dan tidak ada izin tim di sekitar *mock* Anda.
Tidak ada tautan skema. *Mock* Anda dan spesifikasi OpenAPI Anda berada di tempat yang berbeda, sehingga keduanya terpisah.

Ketika Anda mengalami dua atau tiga hal ini, Anda telah melampaui kemampuan alat respons tunggal. Itulah saatnya untuk beralih ke platform *mock* lengkap. Jika Anda mempertimbangkan *tradeoff* anggaran, panduan kami untuk *server mock* API gratis dan murah menjelaskan pilihannya.

Pemicu umum adalah tim *front-end*. Satu *developer* mem-*mock* objek pengguna, yang lain mem-*mock* daftar pesanan, yang ketiga mem-*mock* alur autentikasi. Dengan Mocky, itu adalah tiga tautan yang tidak berhubungan tanpa URL dasar bersama dan tanpa cara untuk bertukar lingkungan. Dengan *server mock* sungguhan, itu adalah tiga *endpoint* dalam satu proyek yang semuanya merespons di bawah satu *host*, dan Anda dapat beralih antara data *staging* dan produksi di satu tempat.

Alternatif Mocky Terbaik: Apidog

Apidog mempertahankan fitur terbaik Mocky, yaitu respons kustom di balik URL yang dapat dibagikan, lalu menambahkan hal-hal yang tidak dimiliki Mocky: persistensi di banyak *endpoint*, data berbasis skema, respons dinamis, dan kolaborasi tim. Anda mendesain *endpoint*, dan Apidog menghasilkan URL *mock* yang di-*hosting* yang mengembalikan kode status kustom, *header*, dan *body* JSON, persis seperti Mocky, tetapi terikat pada desain API Anda yang sebenarnya.

Berikut perbedaan jujurnya. Mocky menjawab “berikan saya satu respons tetap, gratis, sekarang juga.” Apidog menjawab “berikan saya *mock* yang meyakinkan dari seluruh API yang tumbuh bersama proyek saya.”

Beberapa hal yang ditambahkan Apidog di atas kasus penggunaan Mocky:

Mock cerdas dan data yang dihasilkan AI. Daripada meng-*hardcode* satu *body*, Apidog dapat menyimpulkan nilai realistis dari nama *field* dan skema Anda, sehingga email mengembalikan email dan createdAt mengembalikan tanggal.
Dukungan Faker.js. Anda dapat menggunakan Faker.js untuk menghasilkan data *mock* dinamis untuk *payload* yang bervariasi dan realistis pada setiap panggilan.
Aturan *mock* lanjutan. Mengembalikan respons yang berbeda berdasarkan parameter *query* atau konten permintaan, yang merupakan pencocokan permintaan yang tidak dapat dilakukan Mocky.
Mocking berbasis skema. *Mock* Anda dihasilkan dari desain OpenAPI Anda, sehingga keduanya tetap sinkron.
Ruang kerja tim. *Mock* berada dalam proyek bersama dengan kontrol versi dan sinkronisasi waktu nyata, tidak tersebar di seluruh tautan *one-off*.

Anda masih mendapatkan bagian yang sederhana. Butuh satu *endpoint* yang mengembalikan 200 dengan *body* JSON tetap di balik URL? Apidog juga melakukan itu, dan Anda dapat membagikannya dengan tim Anda dalam satu klik.

Mocky vs Apidog Sekilas

Kemampuan	Mocky	Apidog
Status kustom, header, body di balik URL	Ya	Ya
Gratis untuk memulai, tanpa pengaturan	Ya	Ya (paket gratis)
Respons statis tunggal	Ya	Ya
Data dinamis (Faker.js, smart mock)	Tidak	Ya
Pencocokan permintaan / aturan kondisional	Tidak	Ya
Banyak endpoint dalam satu proyek	Tidak	Ya
Mock berbasis skema (OpenAPI)	Tidak	Ya
Ruang kerja tim + versioning	Tidak	Ya
Opsi self-host	Ya (open source)	Cloud + opsi self-host

Jika Anda ingin membandingkan lebih banyak pesaing secara berdampingan, daftar kami tentang alat *mocking* API terbaik dan rangkuman *mocking endpoint* REST kami membahas lebih dalam.

Cara Mengganti URL Mocky di Apidog

Pindah dari satu tautan Mocky itu cepat:

Unduh Apidog dan buat proyek.
Tambahkan *endpoint*, misalnya GET /users/42.
Definisikan responsnya: atur kode status, tambahkan *header*, dan tulis *body* JSON, *field* yang sama dengan yang akan Anda ketikkan di Mocky.
Aktifkan *mock*. Apidog menghasilkan URL *mock* yang di-*hosting* untuk *endpoint* tersebut.
Arahkan *front-end* atau pengujian Anda ke URL baru.

Dari sana Anda dapat menambahkan fitur tambahan, data dinamis, aturan kondisional, lebih banyak *endpoint*, kapan pun Anda membutuhkannya. Anda tidak harus menggunakan fitur-fitur canggih pada hari pertama.

Migrasi jarang dilakukan secara serentak. Sebagian besar tim tetap menggunakan tautan Mocky mereka yang sudah ada sambil membangun kembali *endpoint* penting di Apidog, kemudian menonaktifkan URL lama setelah proyek berada di satu tempat. Karena Apidog dapat membaca file OpenAPI, jika Anda sudah memiliki spesifikasi, Anda dapat mengimpornya dan mendapatkan URL *mock* untuk setiap *endpoint* sekaligus, alih-alih membuat ulang setiap respons secara manual.

Pertanyaan yang Sering Diajukan

Apakah Mocky gratis?

Ya. Mocky gratis dan *open-source* di bawah lisensi Apache 2.0, dan Anda tidak memerlukan akun untuk membuat *mock*. Respons disimpan di sisi *server*, sehingga URL yang Anda dapatkan tetap aktif. Jika Anda membutuhkan lebih dari satu respons tetap, platform yang lebih lengkap seperti Apidog memberi Anda tingkatan gratis dengan data dinamis dan fitur tim.

Apa perbedaan antara mocky.io dan mock server?

URL Mocky adalah satu respons siap pakai. Sebuah *mock server* mensimulasikan seluruh API, dengan banyak *endpoint*, pencocokan permintaan, dan data yang dapat berubah per permintaan. Jika Anda baru mengenal konsep ini, penjelasan kami tentang apa itu API *mock* menjelaskannya dari awal.

Bisakah saya mengembalikan kode status dan header kustom dengan Mocky?

Ya. Itulah tepatnya fungsi Mocky. Anda mengatur kode status, menambahkan *header* apa pun yang Anda inginkan, menulis *body*, dan Mocky menyajikan semuanya dari satu URL. Batasannya adalah selalu respons yang sama, terlepas dari permintaannya.

Kapan saya harus beralih dari Mocky ke platform mock penuh?

Beralihlah ketika Anda membutuhkan lebih dari satu jawaban tetap: data dinamis atau realistis, respons kondisional, beberapa *endpoint* yang terorganisir bersama, atau ruang kerja bersama untuk tim Anda. Sampai saat itu, kesederhanaan Mocky adalah fitur, bukan kekurangan.

Kesimpulan

Mocky adalah cara yang bersih dan gratis untuk menempatkan satu respons HTTP kustom di balik URL, dan untuk kebutuhan statis yang cepat, ini adalah alat yang tepat. Saat Anda membutuhkan data dinamis, pencocokan permintaan, banyak *endpoint*, atau kolaborasi tim, model respons tunggal itu menjadi tidak memadai.

Di situlah Apidog mengambil alih. Ini mencakup pekerjaan yang sama yaitu “mendesain respons di balik URL”, lalu berkembang menjadi *mocking* berbasis skema, dinamis, dan kolaboratif seiring pertumbuhan API Anda. Unduh Apidog untuk membuat URL *mock* pertama Anda secara gratis dan pertahankan saat proyek Anda semakin besar.