Pemantauan API

Mengapa API Membutuhkan Monitoring Khusus

API bukan sekadar halaman di bawah /api/. Itu adalah kontrak. Metode HTTP penting – GET vs POST mengubah maknanya. Header membawa otentikasi, content negotiation, kunci idempoten. Body permintaan adalah input. Kode respons penting (401 vs 403 vs 422 – masing-masing bercerita berbeda). Body respons punya struktur – jalur JSON andalan para integrator. Cek uptime biasa, yang hanya memanggil URL pakai GET, akan melewatkan sebagian besar cara API bisa gagal: JSON tidak valid tetap mengembalikan 200, endpoint otentikasi menerima data salah, webhook dengan skema payload rusak, endpoint mengembalikan 200 tapi ada "status": "error" di dalamnya.

Monitoring API mengatasi ini, memberi kamu kendali atas setiap bagian request dan verifikasi setiap bagian respons. Kamu mengonfigurasi tepat seperti panggilan yang dilakukan integratormu – metode sama, header sama, body sama, auth sama – dan definisi persis kesuksesan – kode tepat, nilai pada jalur JSON, ambang batas waktu respons, batas ukuran.

Konfigurasi Permintaan

Untuk setiap monitor API dalam DiagnoSEO Uptime Monitoring kamu bisa mengonfigurasi:

• Metode HTTP: GET, POST, PUT, PATCH, DELETE, HEAD. Pilih yang digunakan integrator kamu.
• Header Kustom: sebagai objek JSON, misal {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Standar untuk menguji OAuth, JWT, kunci API, content negotiation.
• Body Permintaan: string apa pun – JSON, XML, form-encoded, plain text. Dikirim untuk POST/PUT/PATCH/DELETE.
• Basic auth: username dan password, jika endpoint dilindungi dengan cara ini.
• Kode status yang diharapkan: daftar atau rentang. Default 200-399, tapi kamu bisa memperketat ke satu kode saja (misal persis 201 untuk endpoint pembuatan) atau izinkan kode tertentu (misal 200,202,204).

Pemeriksaan mengikuti maks. 5 redirect, mendekode gzip, mem-parsing Content-Type untuk mendeteksi JSON. Setiap cek merekam kode aktual, waktu respons, ukuran, dan kesalahan jika ada. Beberapa kegagalan berturut-turut (bisa diatur, default 2) akan memicu insiden.

Asersi JSON path

Kode status saja tidak cukup untuk banyak API. Endpoint health bisa mengembalikan 200 dengan body {"status": "degraded", "db": "down"} – tetap 200, tapi kamu pasti ingin tahu. API harga bisa mengembalikan 200 dengan body di mana data.price turun ke null. API mesin pencari bisa mengembalikan 200 dengan results: [], karena indeks rusak.

Untuk kasus seperti ini, konfigurasikan asersi JSON path. Atur jalurnya (misal data.status atau health.checks.db) dan nilai yang diharapkan (misal healthy, true atau angka tertentu). Setiap pemeriksaan, respons didekode dari JSON, dan nilai pada jalur tadi dibandingkan. Ketidakcocokan akan membuat cek gagal, terlepas dari status HTTP.

Sintaks jalur adalah notasi titik dengan tanda kurung: data.items[0].id bisa, begitu pula users.john.email. Nilai yang diasersikan dibandingkan sebagai string, jadi "true" cocok dengan bool true, dan angka cocok baik sebagai string maupun angka.

Pola Autentikasi

Dua gaya auth paling umum langsung didukung. Untuk token Bearer (OAuth, JWT, kunci API) gunakan kolom headers: {"Authorization": "Bearer eyJhbGciOi..."}. Token ditempatkan di konfigurasi monitor dan dikirim setiap pemeriksaan. Untuk basic auth gunakan kolom username/password khusus – disimpan dan digabung jadi header standar.

Jika auth perlu penandatanganan per permintaan atau perlu refresh token, memang lebih rumit. Dua pola masuk akal: (1) konfigurasi token akun layanan berumur panjang khusus monitoring, atau (2) sediakan endpoint health tanpa autentikasi yang mencerminkan status endpoint dilindungi sesungguhnya, dan monitor endpoint itu. Sebagian besar API modern sudah punya solusi semacam ini.

Pola yang Kami Rekomendasikan

• Satu monitor untuk endpoint krusial. Tidak perlu tes semua – pilih 5-10 endpoint yang jika down benar-benar berdampak buruk.
• Gunakan kode tepat. Default 200-399 terlalu permisif untuk API. Endpoint pembuatan harus benar-benar mengembalikan 201; yang idempoten tepat 200; endpoint login tepat 200 (berhasil) atau 401 (gagal terstruktur – bukan 500).
• Kombinasikan status dengan asersi JSON. Bersama-sama menangkap regresi layer transport maupun konten. Status saja tak mendeteksi error konten; asersi JSON sendiri rentan jika ada redirect.
• Atur ambang waktu respons. Degradasi API adalah indikator awal masalah dependensi. Monitor dengan rt_threshold_ms = 800 memberi tahu API melambat sebelum benar-benar down.
• Jaga body tetap kecil. Pemeriksaan setiap menit – body besar cuma membuang bandwidth kedua sisi. Payload minimal tapi representatif sudah cukup.

Kombinasikan dengan Jenis Monitor Lain

Untuk setiap endpoint API, monitor API memverifikasi panggilan berjalan. Monitor ping atau port terpisah memverifikasi host hidup. Pemeriksaan SSL/domain di hostname sama menangkap masalah sertifikat dan pendaftaran. Submonitor DNS menjaga perubahan record yang bisa jadi indikasi peralihan. Kombinasi empat monitor pada API memberi gambaran utuh dengan tumpang tindih minimal.

Konfigurasi

Buka alat, klik "Tambah monitor", pilih tipe "API". Tempel URL. Buka bagian Lanjutan. Pilih metode, tempel header sebagai JSON, tempel body jika perlu, atur basic auth jika dipakai, ketik kode status yang diharapkan (misal 200 atau 200,201). Tambah asersi JSON path bila perlu. Atur interval dan ambang konfirmasi. Simpan. Mulai siklus berikutnya, monitor akan memanggil API kamu secara persis seperti integrator, memvalidasi respons, dan memberi alarm dalam sekejap bila ada regresi.

Pertanyaan yang Sering Diajukan

• Metode HTTP apa saja yang bisa saya gunakan untuk monitor API?

  GET, POST, PUT, DELETE, PATCH, dan HEAD. Sesuaikan metode untuk setiap monitor — untuk endpoint penulisan (POST/PUT/PATCH), body permintaan juga bisa dikonfigurasi sebagai string JSON atau form data.

• Bagaimana cara kerja asersi JSON?

  Kamu masukkan jalur JSON (misal data.status atau results[0].id) dan nilai yang diharapkan. Monitor mengambil respons, parsing sebagai JSON, mengambil jalur tersebut dan membandingkan dengan nilai yang diharapkan. Jika tidak cocok, cek gagal dengan error "assertion failed" yang memperlihatkan nilai sebenarnya.

• Apakah saya bisa mengirim header otentikasi?

  Bisa. Header HTTP kustom bisa diatur per monitor – token Authorization, kunci API, content-type, apapun. Nilai header dienkripsi saat disimpan di database. Untuk Basic Auth ada kolom username/password khusus yang otomatis membubuhkan ke request.

• Bagaimana jika API saya mengembalikan 200 dengan payload error?

  Pola umum: API mengembalikan HTTP 200 tapi body berisi {"status":"error"}. Monitor uptime yang polos akan mengira ini sehat. Pakai asersi JSON status == "ok" untuk menangkapnya — asersi gagal dan monitor akan melaporkan DOWN meskipun HTTP 200.

• Bagaimana menangani API dengan rate limit?

  Atur interval pemeriksaan agar mengikuti batas API (misal interval 5 menit jika API hanya memperbolehkan 12 panggilan/jam). Satu cek monitor dihitung sebagai satu panggilan API dari satu region. Cek multi-region akan menggandakan jumlah panggilan — gunakan single-region jika API kamu punya batas ketat.