Dasar-Dasar Endpoint
Membuat Endpoint
APIs, klik tombol Endpoint Baru.1.
2.
3.
4.
5.
Mode Design-first
Mode Request-first
Mode Antarmuka
Path Endpoint
/users). URL dasar diatur dalam lingkungan, dan Apidog secara otomatis menambahkannya saat membuat permintaan ke endpoint./. Hal ini menjaga desain API Anda tetap bersih, terorganisasi, dan memastikan Anda mendapatkan manfaat penuh dari fitur-fitur Apidog.Mengapa Path Harus Dimulai dengan /
/ disarankan agar sesuai dengan OAS. Tidak memulai path dengan / dapat menyebabkan berbagai masalah kompatibilitas saat menggunakan alat dalam ekosistem OpenAPI./ di awal path memungkinkan pemanfaatan fungsionalitas mock pola URL yang penting untuk keperluan pengujian dan validasi di Apidog.Metode Permintaan
| Metode | Deskripsi |
|---|---|
| GET | Mengambil sumber daya tertentu tanpa efek samping. Menggunakan parameter kueri untuk mengirimkan data. |
| POST | Mengirimkan data untuk diproses dan dapat memiliki efek samping. Data biasanya dikirim dalam body permintaan. |
| PUT | Memperbarui atau mengganti sumber daya tertentu secara keseluruhan. |
| DELETE | Menghapus sumber daya tertentu. |
| OPTIONS | Menanyakan metode HTTP yang didukung oleh sumber daya target. |
| HEAD | Mirip dengan GET, tetapi hanya mengambil header respons. Berguna untuk memeriksa keberadaan dan modifikasi sumber daya tanpa mengunduh konten sumber daya. |
| PATCH | Memperbarui sebagian informasi dari sumber daya tertentu. |
| TRACE | Mengembalikan permintaan yang diterima oleh server. Terutama digunakan untuk keperluan debugging dan diagnostik. |
| CONNECT | Membuat tunnel ke server, biasanya digunakan untuk penerusan permintaan server proxy. |
Metadata Endpoint
| Bidang | Deskripsi |
|---|---|
| Nama | Nama deskriptif yang menjelaskan fungsionalitas endpoint. |
| Status | Status default adalah "Developing". Anda dapat mengubahnya untuk mencerminkan tahapan yang berbeda seperti Testing atau Production. Pelajari lebih lanjut tentang status Endpoint. |
| Maintainer | Menentukan anggota tim Apidog yang bertanggung jawab atas endpoint. Pilih pengguna dari akun Anda untuk menetapkan peran ini. |
| Tag | Kata kunci atau frasa yang mengategorikan atau mendeskripsikan endpoint. Anda dapat membuat tag baru atau memilih dari tag yang sudah ada. |
| Layanan | URL dasar tempat path endpoint ditambahkan. Secara default diatur ke "Inherit from parents", tetapi dapat ditentukan secara manual melalui pengaturan lingkungan. Pelajari lebih lanjut tentang Lingkungan dan layanan. |
| OperationId | Pengidentifikasi unik (operationId dalam OAS) yang membedakan operasi ini dalam API. |
| Deskripsi | Informasi terperinci tentang tujuan dan penggunaan endpoint, dengan dukungan Markdown untuk pemformatan yang lebih baik. |
Bidang Kustom
Permintaan
Parameter Permintaan
Parameter Kueri
?, dan dipisahkan oleh & sebagai berikut: ?id=2&status=available. Parameter ini digunakan untuk memfilter, mengurutkan, atau memodifikasi output dari endpoint API.INFO
Parameter Path
/pets/{id}, Contoh yang salah: /pets/:id.{parameter} dalam URL, lalu menggunakan {{variable}} untuk nilai parameter. Contoh:Disarankan: Letakkan variabel pada nilai parameter path
Tidak disarankan: Letakkan variabel langsung di URL
Jangan Mencampuradukkan {parameter} dan {{variable}}
{parameter}: Kurung kurawal tunggal merepresentasikan parameter path di Apidog. Parameter path adalah placeholder dalam path URL yang berubah secara dinamis menjadi nilai tertentu saat endpoint API diakses.{{variable}}: Kurung kurawal ganda menyertakan variabel dalam permintaan. Variabel ini dapat diganti dengan nilai aktual saat permintaan dikirim, sehingga memungkinkan input yang dinamis dan dapat disesuaikan dalam interaksi API.Mengapa TIDAK Menggunakan {{variable}} dalam Path
{{variable}} tidak sesuai dengan OAS. Mengikuti OAS memungkinkan integrasi yang lancar dengan berbagai alat dalam ekosistem OpenAPI.{{variable}} dalam path akan mencegah penggunaan fungsionalitas mock pola URL di Apidog.Parameter Header
Pelajari Lebih Lanjut
Parameter Body
Pelajari Lebih Lanjut
Mendeskripsikan Parameter
| Properti | Deskripsi |
|---|---|
| Nama | Menentukan nama parameter yang sedang dideskripsikan. Ini adalah bidang wajib dan harus secara akurat merepresentasikan parameter yang sedang didefinisikan. |
| Tipe | Menentukan tipe data dari nilai parameter. Nilai umum mencakup string, number, integer, boolean, array, object, dan lainnya. Properti ini membantu mendefinisikan format dan struktur nilai parameter. |
| Deskripsi | Memberikan penjelasan singkat atau dokumentasi mengenai parameter. Ini membantu pengguna memahami tujuan dan penggunaan parameter. |
| Wajib | Menentukan apakah parameter bersifat wajib untuk permintaan API. Ini adalah nilai boolean (true atau false) yang menunjukkan apakah parameter harus disertakan dalam permintaan. |
| Pengaturan Lanjutan | Mendefinisikan tipe data, format, dan batasan parameter. Ini memungkinkan Anda memberikan informasi terperinci tentang struktur dan konten yang diharapkan dari nilai parameter. |
Type Editor
Skema
JSON atau XML, struktur data perlu diatur. Struktur data dapat mereferensikan skema.Pelajari Lebih Lanjut
Respons dan Contoh
| Komponen | Deskripsi |
|---|---|
| Kode Status HTTP | Tentukan semua status respons potensial yang mungkin dikembalikan endpoint Anda, termasuk respons standar seperti 200 (OK), 404 (Not Found), atau 500 (Server Error). |
| Format Data | Definisikan format respons yang akan dikembalikan API untuk setiap kode status. Ini dapat berupa JSON, XML, HTML, Raw, Binary, atau format lain yang sesuai. |
| Skema | Untuk respons yang membawa data (terutama status 200), jelaskan struktur payload respons secara terperinci. Ini mencakup penentuan tipe, objek bersarang, bidang opsional, dan array. Definisi yang jelas membantu pengembang klien memahami data apa yang diharapkan dan cara menguraikannya. Hanya JSON dan XML yang dapat mengonfigurasi skema. Untuk informasi terperinci, lihat Skema. |
| Contoh | Menyediakan contoh respons sangat penting untuk menggambarkan bagaimana API berperilaku dalam skenario dunia nyata. Contoh idealnya berupa set data sampel yang dikembalikan oleh server saat endpoint dipanggil dengan permintaan yang telah ditentukan sebelumnya. Contoh tersebut harus mencerminkan struktur, format data, dan tipe sebagaimana didefinisikan oleh skema respons. |
Menambahkan Respons
200 OK sering berbeda di berbagai endpoint karena kebutuhan data output yang berbeda, respons error seperti 400 Bad Request dan 404 Not Found cenderung konsisten di berbagai endpoint. Apidog secara cerdas menangani kesamaan ini dengan fitur Komponen Respons, yang memungkinkan penggunaan ulang respons error yang telah ditentukan sebelumnya, sehingga membuat proses dokumentasi API lebih efisien dan perilaku API lebih konsisten.Komponen Respons
Menambahkan Contoh Respons
Pembuatan Contoh Otomatis
Pratinjau Endpoint
Modified at 2026-06-11 10:17:04