Komunitas pengembangan perangkat lunak sedang aktif membahas salah satu prinsip paling fundamental dalam desain API: aturan sakral untuk tidak pernah merusak userspace. Prinsip ini, yang terkenal diperjuangkan oleh pencipta Linux Linus Torvalds , telah menjadi landasan stabilitas API namun juga menimbulkan pertanyaan tentang keseimbangan antara keandalan dan inovasi.
Sifat Bermata Dua dari Stabilitas API
Meskipun prinsip never break userspace melindungi pengguna akhir dari perangkat lunak yang rusak, para pengembang menunjukkan bahwa hal ini hanya menceritakan setengah dari keseluruhan cerita. Kernel Linux mempertahankan kompatibilitas mundur yang ketat untuk antarmuka yang menghadap pengguna, namun dengan bebas merusak API kernel internal tanpa peringatan. Pendekatan ini menyoroti perbedaan penting dalam desain API: tidak semua antarmuka memerlukan tingkat jaminan stabilitas yang sama.
Diskusi komunitas mengungkapkan bahwa mendeklarasikan apa yang stabil di muka lebih penting daripada janji stabilitas menyeluruh. Hal ini memungkinkan pengembang untuk berinovasi di area yang ditandai sebagai tidak stabil sambil mempertahankan keandalan yang kokoh di tempat yang paling penting.
Filosofi API Kernel Linux
- API Userspace: Tidak pernah dirusak, dipelihara tanpa batas waktu untuk kompatibilitas mundur
- API Kernel: Dapat dirusak tanpa peringatan, memungkinkan inovasi internal
- Prinsip Utama: Deklarasikan apa yang stabil di awal, pertahankan jaminan tersebut dengan ketat
Tantangan Kompatibilitas GNU libc
Meskipun kernel berkomitmen pada stabilitas userspace, pustaka C GNU (glibc) menghadirkan tantangan kompatibilitas yang berkelanjutan. Program yang dikompilasi terhadap versi glibc yang lebih baru sering gagal berjalan pada sistem yang lebih lama, memaksa semuanya untuk diupgrade bersamaan. Hal ini menciptakan hambatan praktis bagi upaya stabilitas kernel.
Bahkan jika kernel tidak merusak userspace, GNU libc melakukannya, sepanjang waktu, sehingga efek bersihnya adalah bahwa userspace Linux rusak terlepas dari upaya para maintainer kernel.
Static linking menawarkan satu solusi, memberikan stabilitas yang luar biasa untuk executable. Namun, pembatasan lisensi dengan GNU libc membuat pendekatan ini bermasalah untuk banyak aplikasi komersial, mendorong beberapa pengembang untuk mengeksplorasi alternatif seperti musl libc atau proyek LLVM libc yang sedang berkembang.
Masalah Kompatibilitas GNU libc
- Program yang dikompilasi pada versi libc yang lebih baru tidak dapat berjalan pada sistem yang lebih lama
- Memerlukan upgrade bersamaan di seluruh sistem
- Static linking dengan GNU libc memiliki batasan lisensi LGPL untuk perangkat lunak proprietary
- Solusi alternatif: musl libc (lisensi lebih permisif), LLVM libc (dalam pengembangan)
Versioning API: Kejahatan yang Diperlukan atau Cacat Desain?
Perdebatan meluas ke strategi versioning API, dengan pengembang berbagi pengalaman beragam tentang skema versioning berbasis URL. Banyak yang melaporkan bahwa sebagian besar API tidak pernah berkembang melampaui versi 1, membuat awalan /v1 sebagian besar bersifat seremonial. Ketika perubahan yang merusak memang terjadi, tim sering membuat endpoint yang sepenuhnya baru dengan nama yang berbeda daripada menaikkan nomor versi.
Beberapa pengembang mengadvokasi untuk menyertakan nomor versi dari awal untuk memudahkan transisi di masa depan, sementara yang lain berargumen bahwa hal ini mendorong perubahan yang merusak yang tidak perlu. Diskusi mengungkapkan bahwa versioning yang sukses memerlukan perencanaan yang hati-hati dan overhead pemeliharaan yang signifikan, karena setiap versi menggandakan beban pengujian dan dukungan.
Pola Versioning API yang Diamati
- v1: Versi yang paling umum, seringkali satu-satunya versi yang pernah dirilis
- v2: Jarang, biasanya merepresentasikan redesain "sekarang kami tahu apa yang kami lakukan"
- v3: Lebih umum daripada v2, seringkali mengikuti dengan cepat setelah v2
- v4+: Sangat jarang dalam praktiknya
- Pendekatan alternatif: Endpoint baru dengan nama deskriptif alih-alih nomor versi
Kesederhanaan Autentikasi vs Keamanan
Topik yang sangat kontroversial muncul seputar metode autentikasi API. Meskipun OAuth dan skema autentikasi canggih lainnya menawarkan keamanan yang lebih baik, banyak pengembang berargumen untuk mendukung API key sederhana untuk menurunkan hambatan masuk. Hal ini mencerminkan ketegangan yang lebih luas antara praktik terbaik keamanan dan pengalaman pengembang.
Komunitas menekankan bahwa banyak pengguna API bukanlah insinyur perangkat lunak profesional tetapi lebih kepada salesperson, mahasiswa, atau hobbyist yang membutuhkan akses cepat untuk skrip sederhana. Alur autentikasi yang kompleks dapat mencegah pengguna ini untuk memulai, berpotensi membatasi adopsi dan kegunaan API.
Biaya Perubahan yang Merusak
Pengalaman dunia nyata yang dibagikan dalam diskusi menyoroti efek kaskade dari perubahan API. Pengembang menggambarkan insiden di mana integrasi pihak ketiga menyebabkan kegagalan sistem melalui pola penggunaan yang tidak terduga, dan bagaimana satu perubahan API yang ceroboh dapat merusak ratusan atau ribuan aplikasi downstream.
Hal ini memperkuat mengapa prinsip never break userspace ada: sifat saling terhubung dari perangkat lunak modern berarti bahwa maintainer API memiliki tanggung jawab kepada seluruh ekosistem mereka, bukan hanya pengguna langsung mereka.
Referensi: Everything I know about good API design