Komuniti pembangunan perisian sedang aktif membincangkan salah satu prinsip paling asas dalam reka bentuk API: peraturan suci untuk tidak sekali-kali merosakkan userspace. Prinsip ini, yang terkenal diperjuangkan oleh pencipta Linux Linus Torvalds, telah menjadi asas kepada kestabilan API tetapi juga menimbulkan persoalan mengenai keseimbangan antara kebolehpercayaan dan inovasi.
Sifat Bermata Dua Kestabilan API
Walaupun prinsip jangan sekali-kali rosakkan userspace melindungi pengguna akhir daripada perisian yang rosak, pembangun menunjukkan bahawa ia hanya menceritakan separuh daripada cerita. Kernel Linux mengekalkan keserasian ke belakang yang ketat untuk antara muka yang berhadapan dengan pengguna, tetapi dengan bebas merosakkan API dalaman kernel tanpa amaran. Pendekatan ini menyerlahkan perbezaan penting dalam reka bentuk API: tidak semua antara muka memerlukan tahap jaminan kestabilan yang sama.
Perbincangan komuniti mendedahkan bahawa mengisytiharkan apa yang stabil di hadapan adalah lebih penting daripada janji kestabilan menyeluruh. Ini membolehkan pembangun berinovasi dalam kawasan yang ditandakan sebagai tidak stabil sambil mengekalkan kebolehpercayaan yang kukuh di tempat yang paling penting.
Falsafah API Kernel Linux
- API Ruang Pengguna: Tidak pernah dipecahkan, dikekalkan selama-lamanya untuk keserasian ke belakang
- API Kernel: Boleh dipecahkan tanpa amaran, membenarkan inovasi dalaman
- Prinsip Utama: Isytiharkan apa yang stabil dari awal, kekalkan jaminan tersebut dengan ketat
Cabaran Keserasian GNU libc
Walaupun komitmen kernel terhadap kestabilan userspace, perpustakaan C GNU (glibc) menimbulkan cabaran keserasian yang berterusan. Program yang dikompil terhadap versi glibc yang lebih baharu sering gagal berjalan pada sistem yang lebih lama, memaksa segala-galanya untuk dinaik taraf bersama-sama. Ini mewujudkan halangan praktikal kepada usaha kestabilan kernel.
Walaupun kernel tidak merosakkan userspace, GNU libc melakukannya, sepanjang masa, jadi kesan bersihnya ialah userspace Linux rosak tanpa mengira usaha penyelenggara kernel.
Pemautan statik menawarkan satu penyelesaian, memberikan kestabilan yang luar biasa untuk fail boleh laku. Walau bagaimanapun, sekatan pelesenan dengan GNU libc menjadikan pendekatan ini bermasalah untuk banyak aplikasi komersial, menyebabkan sesetengah pembangun meneroka alternatif seperti musl libc atau projek LLVM libc yang sedang berkembang.
Isu Keserasian GNU libc
- Program yang dikompil pada versi libc yang lebih baharu tidak dapat berjalan pada sistem yang lebih lama
- Memerlukan peningkatan serentak merentasi keseluruhan sistem
- Pautan statik dengan GNU libc mempunyai sekatan pelesenan LGPL untuk perisian proprietari
- Penyelesaian alternatif: musl libc (lesen yang lebih permisif), LLVM libc (dalam pembangunan)
Versi API: Kejahatan Yang Perlu atau Kecacatan Reka Bentuk?
Perdebatan meluas kepada strategi versi API, dengan pembangun berkongsi pengalaman bercampur mengenai skim versi berasaskan URL. Ramai melaporkan bahawa kebanyakan API tidak pernah maju melepasi versi 1, menjadikan awalan /v1 sebahagian besarnya sebagai upacara. Apabila perubahan yang merosakkan berlaku, pasukan sering mencipta titik akhir baharu sepenuhnya dengan nama yang berbeza daripada menambah nombor versi.
Sesetengah pembangun menyokong untuk memasukkan nombor versi dari awal untuk memudahkan peralihan masa depan, manakala yang lain berhujah ini menggalakkan perubahan yang merosakkan yang tidak perlu. Perbincangan mendedahkan bahawa versi yang berjaya memerlukan perancangan yang teliti dan overhed penyelenggaraan yang ketara, kerana setiap versi mendarabkan beban ujian dan sokongan.
Corak Penomboran Versi API yang Diperhatikan
- v1: Versi yang paling biasa, selalunya satu-satunya versi yang pernah dikeluarkan
- v2: Jarang berlaku, biasanya mewakili reka bentuk semula "sekarang kami tahu apa yang kami lakukan"
- v3: Lebih biasa daripada v2, selalunya mengikuti dengan pantas selepas v2
- v4+: Amat jarang berlaku dalam amalan
- Pendekatan alternatif: Titik akhir baharu dengan nama deskriptif dan bukannya nombor versi
Kesederhanaan Pengesahan Berbanding Keselamatan
Topik yang sangat kontroversial muncul mengenai kaedah pengesahan API. Walaupun OAuth dan skim pengesahan canggih lain menawarkan keselamatan yang lebih baik, ramai pembangun berhujah untuk menyokong kunci API yang mudah untuk menurunkan halangan kemasukan. Ini mencerminkan ketegangan yang lebih luas antara amalan terbaik keselamatan dan pengalaman pembangun.
Komuniti menekankan bahawa ramai pengguna API bukanlah jurutera perisian profesional tetapi sebaliknya jurujual, pelajar, atau penggemar yang memerlukan akses pantas untuk skrip mudah. Aliran pengesahan yang kompleks boleh menghalang pengguna ini daripada bermula, berpotensi mengehadkan penerimaan dan kegunaan API.
Kos Perubahan Yang Merosakkan
Pengalaman dunia sebenar yang dikongsi dalam perbincangan menyerlahkan kesan berturut-turut perubahan API. Pembangun menerangkan insiden di mana integrasi pihak ketiga menyebabkan kegagalan sistem melalui corak penggunaan yang tidak dijangka, dan bagaimana satu perubahan API yang cuai boleh merosakkan beratus-ratus atau beribu-ribu aplikasi hiliran.
Ini mengukuhkan mengapa prinsip jangan sekali-kali rosakkan userspace wujud: sifat saling berkaitan perisian moden bermakna bahawa penyelenggara API mempunyai tanggungjawab kepada seluruh ekosistem mereka, bukan hanya pengguna langsung mereka.