Validasi di batas API adalah pertanyaan tentang lapis mana yang mengerjakan pemeriksaan: antarmuka yang dijalankan di perangkat pengguna, layanan yang berjalan di server, atau keduanya. Jawaban yang tergesa-gesa biasanya menghasilkan pemeriksaan berganda yang tidak konsisten, atau sebaliknya, masukan yang lolos tanpa diperiksa sama sekali. Halaman ini membahas pembagian tugas yang lazim dipakai beserta bentuk jawaban yang membuat hasilnya mudah ditindaklanjuti.
Di mana sebaiknya validasi dijalankan?
Jawaban ringkasnya adalah di kedua tempat, tetapi dengan tugas yang berbeda. Klien bertugas memberi umpan balik cepat dan mencegah pengiriman yang jelas salah. Server bertugas menjadi penentu akhir, karena hanya di sanalah aturan dapat dirahasiakan, diperbarui, dan dijamin berlaku untuk semua pemanggil.
Pembagian ini muncul dari kenyataan bahwa apa pun yang berjalan di perangkat pengguna dapat diubah. Pemeriksaan di klien adalah kenyamanan, bukan pengamanan. Menempatkan seluruh keputusan di klien berarti membiarkan setiap pemanggil menentukan sendiri aturannya, dan hasilnya berbeda-beda antarperamban, antarversi, dan antarpemanggil.
Sebaliknya, menempatkan seluruh pemeriksaan di server tanpa umpan balik di klien membuat pengalaman menjadi berat. Pengguna menunggu perjalanan ke jaringan hanya untuk mengetahui bahwa satu lambang salah tempat. Pemeriksaan bentuk yang sederhana di klien menghilangkan sebagian besar penantian itu.
Pembagian tugas itu dapat diringkas dalam tabel berikut.
| Pekerjaan | Klien | Server |
|---|---|---|
| Pembersihan pemisah dan bentuk huruf | Cocok | Berguna sebagai penguat |
| Pemeriksaan panjang dan kumpulan karakter | Cocok untuk umpan balik cepat | Wajib sebagai penentu akhir |
| Perhitungan digit pemeriksa yang diterbitkan | Cocok | Wajib sebagai penentu akhir |
| Pencarian ke daftar resmi | Tidak boleh | Hanya melalui layanan Anda sendiri |
| Penetapan keputusan akhir | Tidak pernah | Selalu |
Tabel ini bukan aturan yang berlaku umum, melainkan ringkasan pilihan yang paling sering bertahan lama. Yang penting adalah setiap baris memiliki satu penentu akhir yang jelas, sehingga tidak ada pemeriksaan yang dijalankan dua kali dengan aturan yang berbeda dan tidak ada pula pemeriksaan yang terlewat karena masing-masing lapis mengira lapis lain yang mengerjakannya.
Yang cocok diperiksa di klien
Pemeriksaan yang cepat, tidak memerlukan rahasia, dan hasilnya tidak perlu dirahasiakan adalah calon terbaik untuk dijalankan di klien. Pembersihan pemisah, penyamaan bentuk huruf, pemeriksaan panjang, dan pemeriksaan kumpulan karakter termasuk kelompok ini karena semuanya dapat dijalankan seketika tanpa akses jaringan.
Pemeriksaan digit pemeriksa juga sering dijalankan di klien, asalkan aturannya memang diterbitkan untuk umum. Hasilnya memberi tahu pengguna lebih awal bahwa tulisannya kemungkinan salah salin, sehingga ia masih sempat memperbaikinya sebelum mengirimkan apa pun.
Yang perlu dihindari di klien adalah pemanggilan ke daftar resmi. Pemeriksaan seperti itu memerlukan kredensial yang tidak boleh berada di perangkat pengguna, dan hasilnya sering kali tidak boleh diungkapkan kepada sembarang pemanggil. Bila terpaksa dilakukan, pemanggilan itu harus melewati layanan perantara Anda sendiri.
Yang hanya bisa diperiksa di server
Server memegang aturan yang menjadi penentu akhir. Di sinilah ditetapkan apakah sebuah masukan diterima, ditolak, atau ditandai untuk ditinjau manusia. Server juga yang menyimpan versi aturan yang sedang berlaku, sehingga hasil pemeriksaan pada waktu yang berbeda dapat dipertanggungjawabkan.
Server pula tempat pemeriksaan yang bergantung pada data lain dijalankan: apakah nomor itu sudah pernah dipakai, apakah ia bertentangan dengan data yang tersimpan, atau apakah ia menunjuk pada sesuatu yang memang boleh diakses pemanggil. Pemeriksaan semacam ini tidak dapat dipindahkan ke klien karena memerlukan data yang tidak ada di sana.
Selain itu, server bertugas menyeragamkan masukan. Dua pemanggil yang mengirim bentuk tulisan berbeda harus diperlakukan sama. Penyeragaman itu juga yang membuat pencatatan dan penelusuran menjadi masuk akal, karena nilai yang tercatat selalu berada dalam bentuk yang sama.
Server juga tempat pencatatan dilakukan. Setiap pemeriksaan yang ditolak sebaiknya meninggalkan jejak yang cukup untuk menjelaskan sebabnya, tanpa menyimpan nilai yang tidak diperlukan. Jejak itu berguna ketika ada pemanggil yang melaporkan bahwa masukannya seharusnya diterima, karena Anda dapat menunjukkan aturan mana yang menolaknya dan pada lapis mana penolakan itu terjadi.
Bentuk jawaban yang baik dari sebuah API seperti apa?
Jawaban yang baik selalu membedakan tiga hal: bentuk masukan, hasil perhitungan digit pemeriksa, dan keputusan akhir. Menggabungkan ketiganya menjadi satu kata lulus atau gagal membuat pemanggil tidak dapat menampilkan pesan yang tepat kepada penggunanya.
Untuk setiap masukan yang ditolak, sertakan penanda yang menunjuk pada bagian yang bermasalah. Penanda berupa kode yang stabil lebih baik daripada kalimat, karena pemanggil dapat menerjemahkannya ke bahasanya sendiri. Kalimat yang dikirim apa adanya dari server akan muncul dalam bahasa yang tidak dikenal sebagian pengguna.
Sertakan pula keadaan khusus untuk masukan yang hanya dapat diperiksa bentuknya. Bila sebuah skema tidak menerbitkan aturan perhitungan, jawaban tidak boleh dibuat seolah-olah pemeriksaan sudah tuntas. Alat validasi nomor memisahkan keadaan ini dari keadaan tidak valid agar perbedaannya terlihat, dan pembahasannya diuraikan pada nomor tanpa digit pemeriksa.
Perhatikan juga ukuran jawaban. Menyertakan seluruh catatan aturan pada setiap jawaban membuat pesannya membengkak tanpa menambah kejelasan. Cukup sebutkan penanda aturan, hasil per lapis, dan kode kesalahan yang stabil. Rincian aturan dapat disediakan melalui titik masuk terpisah bila memang diperlukan oleh pemanggil.
Terakhir, tentukan perilaku untuk masukan yang tidak dikenal. Apakah pemanggil menerima jawaban bahwa aturannya tidak tersedia, atau ia menerima galat permintaan yang salah bentuk? Kedua pilihan dapat dibenarkan, tetapi harus dipilih dengan sadar dan diberitahukan kepada pemanggil.
Batas antara pemeriksaan bentuk dan pencarian ke daftar resmi
Pemeriksaan bentuk dapat dijalankan tanpa menghubungi siapa pun. Ia hanya memerlukan aturan susunan nomor. Sedangkan pencarian ke daftar resmi memerlukan hak akses, jaringan, dan izin dari pemilik data. Dua pekerjaan itu sering dianggap satu karena hasilnya sama-sama berupa jawaban sah atau tidak sah.
Mencampur keduanya menimbulkan kesalahan yang mahal. Sistem bisa melaporkan nomor yang bentuknya benar sebagai sah, padahal yang terjadi hanyalah perhitungan digit pemeriksa yang berhasil. Sebaliknya, sistem dapat menolak nomor yang bentuknya tidak lazim padahal nomor itu benar-benar terdaftar.
Jaga jarak antara keduanya secara terbuka. Beri nama yang berbeda pada kedua hasil, simpan keduanya secara terpisah, dan jangan pernah memakai hasil yang satu untuk menyimpulkan yang lain. Pemisahan ini juga memudahkan Anda menjelaskan kepada pengguna apa yang sebenarnya sudah diperiksa.
Untuk pengembang: kontrak kesalahan dan versi aturan
Sepakati kode kesalahan lebih dahulu sebelum menulis kodenya. Kode yang stabil memungkinkan pemanggil memperbarui tampilannya tanpa menunggu rilis di sisi server, dan memungkinkan Anda mengubah kalimat penjelasan tanpa merusak pemanggil yang sudah ada.
Sertakan versi aturan pada setiap jawaban. Ketika hasil pemeriksaan berubah karena aturannya diperbarui, versi itu menjelaskan mengapa masukan yang dahulu diterima sekarang ditolak. Tanpa keterangan tersebut, perubahan aturan akan tampak seperti kerusakan.
Tetapkan juga batas ukuran dan jumlah. Pemeriksaan massal sebaiknya tidak dikirim sebagai ribuan permintaan satu per satu, melainkan melalui titik masuk tersendiri yang menerima berkas. Batas itu perlu diumumkan lebih dahulu agar pemanggil dapat menyesuaikan cara pengirimannya, dan agar penolakan karena ukuran yang berlebihan tidak tertukar dengan penolakan karena isi yang salah. Rancangan untuk keperluan itu dibahas pada alur validasi massal untuk daftar nomor besar.
Seluruh nilai dan contoh yang dipakai dalam pembahasan ini adalah rekaan untuk keperluan penjelasan. Halaman ini tidak memuat keterangan tentang pemanggil, layanan, atau sistem mana pun yang benar-benar beroperasi, dan tidak ada contoh nomor yang boleh dibaca sebagai data nyata.
Langkah berikutnya
Tuliskan daftar pemeriksaan Anda, lalu tandai setiap butir dengan lapis yang mengerjakannya. Bila ada butir yang ditandai di dua lapis, tentukan mana yang menjadi penentu akhir. Setelah itu, gunakan alat validasi nomor untuk melihat bagaimana hasil tiap skema ditampilkan, dan bandingkan dengan pembahasan cara kerja validasi nomor untuk memastikan pembagian lapisnya konsisten. Catatan konsistensi bidang pada data uji melengkapi hal ini dari sisi penyiapan berkas ujinya.