Apa itu siklus hidup API?

API adalah seperangkat aturan atau protokol yang memungkinkan aplikasi perangkat lunak berkomunikasi satu sama lain untuk bertukar data, fitur, dan fungsionalitas. Ada siklus hidup produsen API—berfokus pada pembuatan dan distribusi API—dan siklus hidup konsumen API, yang berpusat pada penggunaan API dari sudut pandang konsumen. Artikel ini berfokus pada siklus hidup produsen API.

Tidak ada satu siklus hidup produsen API universal. Anda mungkin melihat variasi yang berbeda dari sumber yang berbeda, tetapi siklus hidup umumnya mencakup tahapan berikut: merencanakan, merancang, mengembangkan, menguji, menerapkan, memantau, dan menghentikan penggunaan.

Platform pengelolaan API sering digunakan untuk membantu mengatur upaya di seluruh siklus hidup API, dan untuk memusatkan strategi API, tata kelola, dokumentasi, dan direktori di seluruh lingkungan TI. Banyak platform menyertakan kemampuan analitik canggih dan alat untuk penemuan dan monetisasi API yang membantu organisasi mendapatkan hasil maksimal dari API mereka.

Pertimbangan dan pemahaman tentang seluruh siklus hidup API membantu tim pengembangan mengalokasikan sumber daya dengan lebih efisien, membuat jadwal pengiriman yang realistis, memberi informasi kepada semua pemangku kepentingan sepanjang proses, dan memastikan bahwa API memenuhi persyaratan bisnis. Pada dasarnya, siklus hidup yang dipikirkan dengan matang dan dieksekusi membantu memberikan API yang berkinerja tinggi dan aman serta pengalaman pengguna yang lebih kuat.

Manajemen siklus hidup API menyeluruh terdiri dari beberapa tahapan utama, dimulai dengan perencanaan awal dan akhir, sering kali, tetapi tidak selalu, dengan penghentian penggunaan atau penggantian. Sebagai contoh, mari kita pertimbangkan perusahaan perangkat lunak yang memutuskan untuk membangun API untuk menyinkronkan data pelanggannya dengan alat bisnis seperti tiket dukungan, sistem akuntansi, platform manajemen proyek, dan banyak lagi.

Membangun API dimulai dengan menjawab beberapa pertanyaan mendasar: Mengapa API ini diperlukan, untuk siapa, bagaimana akan digunakan, dan bagaimana keberhasilan akan diukur? 

Kekhususan tentang tujuan proyek API dapat membantu memperjelas fitur dan fungsionalitas apa yang perlu dimiliki desain API. Dalam contoh pengembangan perangkat lunak, tujuan API adalah untuk memastikan bahwa data pelanggan dapat berpindah dengan lancar antara aplikasi dan platform yang digunakan atau rencananya akan digunakan perusahaan. 

Dalam fase perencanaan ini, organisasi:

• Meninjau potensi manfaat bisnis dari API
• Menjelaskan bagaimana API ini akan memenuhi kebutuhan bisnis
• Memastikan tidak ada API atau produk lain yang tersedia di pasar digital integrasi native yang dapat melakukan apa yang diperlukan (pada dasarnya, mengonfirmasi bahwa membangun API ini diperlukan)
• Menggambarkan dengan jelas aplikasi dan platform mana yang akan bergantung pada API dan bagaimana API akan berintegrasi dengan alur kerja yang ada.

Selanjutnya, tim harus mendiskusikan pengguna potensial dan contoh penggunaan. Apakah ini murni untuk penggunaan internal? Tim mana yang akan menggunakan API ini, dan untuk apa? Apakah ada masalah keamanan yang harus ditangani dalam fase desain dan pengembangan? Dan yang terpenting, siapa yang akan bertanggung jawab atas setiap fase produksi API?

Menetapkan garis waktu untuk penyelesaian proyek membantu memastikan bahwa proyek tetap sesuai anggaran. Yang penting, jadwal harus realistis dan fleksibel. 

Tim akan menjawab pertanyaan seperti: Apakah ada tanggal tertentu, seperti tanggal peluncuran fitur baru, yang harus dipenuhi? Apakah ada tim keamanan atau kepatuhan hukum atau pemangku kepentingan lain yang perlu menyetujuinya sebelum API ini dapat digunakan? 

Di mana dokumentasi dan informasi lain tentang API disimpan dan disediakan untuk pengembang dan pengguna? Di mana perubahan kode akan dilacak dan disimpan?

Menjawab jenis pertanyaan ini di awal membantu menetapkan rencana yang jelas untuk seluruh siklus hidup.

Sementara tahap perencanaan menggambarkan hasil yang diinginkan, tahap desain mendefinisikan bagaimana tim berencana untuk mencapainya. Sepanjang proses desain, tim desain API memutuskan bagaimana API harus dibangun untuk memenuhi persyaratan yang diperinci dalam fase perencanaan. 

Tim harus membuat keputusan desain mengenai protokol dan gaya arsitektur yang akan digunakan API. Keputusan ini mungkin didasarkan pada arsitektur API yang ada di organisasi, atau pada kasus penggunaan yang dimaksudkan untuk API baru ini.

Misalnya, kerangka kerja dan arsitektur API umum termasuk REST, GraphQL dan gRPC; masing-masing memiliki kekuatan dan kelemahannya sendiri. 

• REST: Sederhana, intuitif dan ada di mana-mana, tetapi tidak ideal untuk kueri kompleks dan tidak menawarkan struktur penulisan yang kuat.
  
  
• GraphQL: Efisien, dengan struktur penulisan yang kuat dan dokumentasi bawaan. Tetapi GraphQL juga bisa rumit dan membutuhkan lebih banyak pengaturan dan keahlian khusus daripada REST.
  
  
• gRPC: Cepat, dengan struktur penulisan yang kuat, pembuatan kode otomatis, dan streaming dua arah. gRPC sering digunakan untuk komunikasi layanan mikro. Tetapi sebagai kerangka kerja yang lebih baru, mungkin ada kurva pembelajaran, dan format dokumentasi bersifat biner daripada yang dapat dipahami manusia. 

Dalam merancang API, tim juga akan memutuskan jenis autentikasi apa yang sesuai (seperti OAuth 2.0) dan apakah API harus berada di belakang API Gateway.

Dokumen spesifikasi menjelaskan struktur, perilaku, dan fungsionalitas API dengan cara standar. Dokumen ini menyediakan sumber kebenaran tunggal dengan informasi tentang bagaimana API dibangun, apa yang dapat dilakukannya, dan bagaimana berinteraksi dengannya. 

Spesifikasi standar yang paling populer adalah spesifikasi OpenAPI, yang memungkinkan pengembang untuk menentukan jalur, metode, parameter, metode autentikasi, dan banyak lagi. OpenAPI secara khusus digunakan untuk REST API dan mendukung seperangkat alat sumber terbuka yang disebut Swagger, yang menawarkan pembuatan kode, pengeditan, dan pembuatan dokumentasi otomatis.

Untuk GraphQL, spesifikasi yang setara adalah skema GraphQL, kontrak dengan struktur kuat yang ditulis dalam bahasa definisi skema, atau SDL, format yang dapat dibaca manusia. Ekosistem GraphQL menawarkan beberapa alat berbeda yang memanfaatkan skema ini dengan cara yang menawarkan fungsionalitas serupa dengan OpenAPI; misalnya, GraphiQL adalah ekosistem pengembangan terintegrasi dalam browser (IDE) untuk digunakan pengembang sebagai sandbox. 

Untuk gRPC, Protocol Buffers, atau protobuf, adalah format serialisasi dan bahasa definisi antarmuka (IDL) yang berfungsi sebagai format file yang paling umum digunakan untuk spesifikasi. Protobuf tidak menawarkan pengujian interaktif, meskipun ada UI web yang memungkinkan untuk ini. 

Pada tahap ini, pengembang memulai pengodean, mengikuti rencana desain API yang diuraikan pada langkah sebelumnya. Sistem kontrol versi digunakan untuk melacak versi dan perubahan kode selama proses pengembangan.

Standar industri untuk sistem kontrol versi adalah Git, sepotong perangkat lunak sumber terbuka yang melacak perubahan kode yang disimpan secara lokal di perangkat pengembang. Pengembang menggunakan Git untuk membuat, mengelola, dan melacak perubahan pada kode mereka, tetapi kemudian membutuhkan tempat agar kode tersebut dapat diakses oleh mereka sendiri dan orang lain. 

GitHub adalah layanan hosting Git paling populer, menawarkan tingkatan gratis dan berbayar, memungkinkan penyimpanan, pengambilan, dan kolaborasi repositori kode Git. Ada alternatif untuk hosting repositori Git, termasuk GitLab, AWS CodeCommit, dan Microsoft Azure Repos.

Pengujian API dilakukan selama dan setelah fase pengembangan API; pengujian berkelanjutan membantu pengembangan dengan mengungkapkan kerentanan dan kebutuhan, dan memungkinkan pembaruan rutin. 

Pengujian unit melibatkan mengisolasi bagian-bagian kecil dari kode dan mengujinya secara individual. Dalam contoh API perusahaan perangkat lunak kami, katakanlah tim perlu menguji respons untuk permintaan untuk mengambil informasi pengguna. Perintah GET dimaksudkan untuk mengambil nama pengguna dan alamat email dari nomor ID pengguna tersebut dalam database pelanggan. Pengujian unit akan mencakup tindakan untuk memastikan bahwa permintaan GET ini mengambil informasi yang dimaksud dan bahwa permintaan untuk ID pengguna yang tidak ada memberikan pesan kesalahan yang sesuai.

Pengujian integrasi umumnya dijalankan setelah pengujian unit dan digunakan untuk mendeteksi masalah yang terlewat saat pengujian unit. Pengujian integrasi membantu memastikan bahwa beberapa komponen atau layanan dapat berkomunikasi sebagaimana dimaksud melalui API. 

Kembali ke contoh kita, katakanlah bahwa salah satu fitur API adalah bahwa webhook, atau notifikasi, dikirim dari satu sistem ke sistem lain dalam kasus peristiwa tertentu, seperti penambahan pelanggan baru. Untuk memastikan ini berfungsi, tes integrasi disiapkan dengan server palsu yang menerima pemberitahuan, dan mengambil tindakan yang diharapkan, ketika informasi pelanggan baru ditambahkan ke CRM. Proses ini diulang untuk semua integrasi.

Pengujian kontrak API memastikan bahwa API melakukan apa yang diharapkan pengguna. Kontrak biasanya disusun sebagai file spesifikasi OpenAPI, yang merupakan dokumen standar yang dapat dibaca mesin yang menjabarkan elemen fungsionalitas dan kemampuan API. File spesifikasi API biasanya ditulis dalam JSON atau YAML dan mencakup elemen seperti titik akhir API, metode autentikasi, format spesifik permintaan dan tanggapan yang dapat diterima, metadata, dan parameter input.

Menilai kinerja API biasanya melibatkan evaluasi kecepatan dan efisiensinya. Pada tahap ini, penguji akan mengukur waktu respons kueri, tingkat kesalahan, penggunaan sumber daya (seperti penggunaan CPU dan memori), latensi, dan throughput. Memahami kinerja API dalam tahap ini dapat membantu mengungkapkan hambatan atau redundansi yang dapat memperlambat pengalaman pengguna.

API sering digunakan untuk mengirimkan data sensitif, sehingga pengujian keamanan menjadi komponen penting. Pengujian keamanan API pada dasarnya mencoba untuk membobol API dengan berbagai cara untuk memastikan keamanan dan stabilitas. Upaya tersebut mungkin termasuk pengujian validasi input untuk memastikan data hanya diterima ketika dimasukkan dalam format yang telah disetujui sebelumnya. 

Pengujian validasi input mencari berbagai jenis serangan. Jenis serangan yang umum termasuk injeksi SQL, di mana pelaku jahat memasukkan kode berbahaya ke dalam aplikasi. SQL adalah bahasa yang digunakan untuk berkomunikasi dengan database, dan perintah SQL universal tertentu dapat memicu respons yang tidak sah, seperti daftar semua pengguna. 

Metode pengujian keamanan lainnya termasuk pengujian autentikasi, yang memastikan bahwa langkah-langkah keamanan identifikasi seperti biometrik bekerja dengan benar, dan pengujian otorisasi, yang memastikan bahwa pengguna hanya dapat mengakses fitur yang disetujui untuk mereka akses. 

Pengujian keamanan dilakukan selama dan setelah fase pengembangan, dan fitur kecerdasan buatan (AI) dan otomatisasi baru meningkatkan kekuatan dan akurasi pengujian ini. Alat pengujian keamanan AI dapat secara otomatis menghasilkan tes, memindai kode untuk bug, menganalisis data kinerja untuk membantu memprediksi masalah dan menandai perilaku anomali, dan banyak lagi.

Dalam industri seperti layanan kesehatan dan keuangan, peraturan, undang-undang, dan pedoman ada untuk melindungi keselamatan, keamanan, dan privasi pengguna. Contohnya termasuk HIPAA (informasi kesehatan Amerika), GDPR (informasi pribadi UE), dan CCPA (informasi pribadi California). 

Pengujian kepatuhan adalah pengujian yang memastikan API mematuhi hukum dan pedoman yang berlaku. Misalnya, GDPR memberikan “hak untuk dilupakan,” yang berarti bahwa pengguna dapat meminta penghapusan lengkap data mereka tanpa penundaan yang tidak semestinya. Pengujian kepatuhan untuk API yang sesuai dengan GDPR akan memerlukan memastikan bahwa aturan ini diikuti.

Tahap penerapan adalah peluncuran API. API telah diuji terkait fungsionalitas, keamanan, dan kepatuhan, dan siap digunakan. Pada tahap penerapan, API beralih dari lingkungan pengujian ke lingkungan produksi sebenarnya. Terdapat beberapa langkah yang dilakukan dalam menerapkan API.

Sebelum penerapan, tim harus melakukan ulasan lain untuk memastikan bahwa infrastruktur pendukung, dokumentasi API, dukungan pengguna, distribusi dan komunikasi strategi, dan protokol pemantauan semuanya selesai dan siap digunakan. Daftar periksa ini mungkin mencakup penskalaan server, mengonfigurasi peringatan dan notifikasi, membuat halaman FAQ, mengirim pengumuman ke pelanggan (atau pengumuman publik), dan banyak lagi.

CI/CD, yang merupakan singkatan dari Integrasi berkelanjutan/penerapan berkelanjutan, adalah serangkaian praktik yang mengotomatiskan dan merampingkan pengembangan perangkat lunak, pengujian, dan siklus pengiriman. Ini adalah praktik mendasar dalam metodologi DevOps. Seperti halnya aplikasi perangkat lunak, API juga biasanya digabungkan dalam pipeline CI/CD untuk merampingkan dan mengotomatiskan penerapan, pengujian, dan pembaruan API. 

Sebuah API Gateway adalah lapisan perangkat lunak yang menyediakan satu titik masuk bagi klien untuk mengakses berbagai layanan backend, atau beberapa instance layanan backend. Gateway API dapat menawarkan beberapa keuntungan:

• Kesederhanaan: Klien hanya perlu melacak satu URL layanan, bukan banyak URL
  
  
• Penyeimbangan beban: Organisasi bisa mendistribusikan lalu lintas untuk satu layanan di beberapa instance untuk menyebarkan beban dan menghindari hambatan kinerja
  
  
• Keamanan dan tata kelola: Gateway dapat digunakan untuk menerapkan protokol keamanan dan tata kelola standar di banyak API. 
  
  
• Caching: Gateway dapat membantu dengan caching dengan menyimpan data yang sering diakses di beberapa layanan. Kemampuan ini membantu mempercepat respons dan meningkatkan kinerja.

Organisasi sering mengeluarkan rilis beta untuk memilih pengguna untuk menguji API sebelum sepenuhnya merilisnya ke publik. Hal ini memungkinkan organisasi untuk menemukan dan memperbaiki bug, meminta masukan, mengukur kinerja, dan mempromosikan API di lingkungan yang lebih aman dan lebih terkontrol.

Setelah daftar periksa dan peluncuran beta selesai, saatnya untuk “perubahan total” dan sepenuhnya melakukan pemindahan API. Proses ini mungkin termasuk memulai strategi distribusi untuk lebih menginformasikan tentang API kepada pelanggan internal atau eksternal dan mendorong penggunaannya. Proses distribusi mungkin juga mencakup penerbitan panduan pengguna dan penjangkauan publik lainnya, memperbarui situs web atau direktori API, dan menyesuaikan pengaturan untuk mengaktifkan akses instan daripada memerlukan autentikasi pribadi.

Salah satu manfaat utama dari pemahaman dan perencanaan untuk siklus hidup API penuh adalah memastikan bahwa pemantauan, observabilitas, dan pemeliharaan menjadi fokus, sejak awal. Pekerjaan belum selesai saat peluncuran; masih ada pekerjaan yang harus dilakukan. Pemantauan API adalah proses berkelanjutan, dirancang untuk melihat bagaimana kinerja API di dunia nyata, secara real-time. 

Metrik utama untuk pemantauan meliputi waktu respons, atau berapa lama waktu yang dibutuhkan API untuk menanggapi permintaan; tingkat kesalahan, atau persentase permintaan yang gagal; throughput dan lalu lintas, atau jumlah permintaan yang dapat ditangani API; dan analisis infrastruktur, yang mengukur ketegangan dan kesehatan server.

Elemen pemeliharaan disediakan sebagai respons terhadap data yang dikumpulkan oleh alat pemantauan. Pemeliharaan dapat berupa perbaikan bug, pengoptimalan kinerja, atau bahkan penambahan fitur atau kemampuan baru.

Dalam contoh CRM kami, alat pemantauan mungkin mendeteksi bahwa latensi tinggi ketika data pelanggan dikirim dari satu platform ke platform lainnya; fase pemeliharaan dapat mengatasi hal ini dengan mengurangi redundansi kode, menyempurnakan pengaturan caching, atau memindahkan server agar lebih dekat dengan pelanggan yang mereka layani.

Akhir dari siklus hidup API sama pentingnya, dinamis, dan informatif seperti tahap lainnya.

Pembuatan versi adalah proses yang panjang untuk mempertahankan kemanjuran API melalui pembaruan selama masa aktif. Kunci dalam pembuatan versi adalah menawarkan perubahan dan peningkatan tanpa merusak fungsionalitas yang ada untuk pengguna yang sudah mapan. 

Untuk perbaikan bug sederhana dan sejenisnya, pembaruan biasanya dikeluarkan tanpa menerapkan versi API baru, karena perubahan kecil ini dianggap “tidak merusak.” Tetapi untuk perubahan yang “merusak”, di mana versi baru tidak kompatibel dengan versi yang ingin diganti, praktik yang sebaiknya dilakukan adalah memperkenalkan perubahan sebagai versi baru.

Komunikasi, baik awal maupun sering, adalah kunci untuk pembuatan versi. Praktik umum adalah mendukung versi paralel: versi lama tetap aktif dan fungsional bersama versi baru, dan pengembang mengomunikasikan perubahan untuk mendorong pengguna untuk bermigrasi ke versi baru. Setelah semua atau cukup pengguna telah bermigrasi, versi lama dapat dinonaktifkan.

Penghentian adalah penghapusan permanen dan penonaktifan API. Tidak semua API dihentikan, tetapi pada akhirnya mengganti API adalah hal biasa. Ada beberapa alasan mengapa API mungkin dihentikan:

• Versi baru memberikan kinerja yang unggul
• Kebutuhan kepatuhan atau keamanan tidak lagi terpenuhi secara memadai 
• Perubahan bisnis atau keuangan dalam organisasi
• Ketidaksesuaian dengan perangkat lunak yang lebih baru

Setelah dihentikan penggunaannya, API tidak akan berfungsi lagi. Tetapi ada beberapa tahap yang dapat membantu meringankan transisi ini.

Penghentian API membutuhkan diskusi. Apakah perlu untuk menghentikan API, dan mengapa? Apa yang akan menjadi alternatifnya, jika ada? Siapa yang perlu diberi tahu tentang masa penghentian yang akan datang?

Biasanya, organisasi akan mengumumkan bahwa API akan mencapai batas waktu penghentian. Pengumuman ini mencakup semua informasi yang diperlukan untuk pengguna API, seperti mengapa perubahan ini terjadi, kapan itu akan terjadi, dan tindakan apa yang perlu diambil pengguna, jika ada. 

Kemudian API secara resmi tidak digunakan lagi. API pada titik ini tetap beroperasi tetapi tidak akan menerima pembaruan atau fitur baru. Periode penghentian penggunaan dirancang untuk memberikan waktu dan kesadaran kepada pengguna untuk melakukan penyesuaian yang diperlukan.

“Persiapan penghentian” adalah saat API publik sepenuhnya dimatikan, di mana permintaan tidak akan lagi dijawab dan klien yang mencoba memanggil API akan menerima pesan kesalahan. Sebaiknya perbarui dokumentasi untuk mencerminkan perubahan ini, dan bebaskan ruang server atau infrastruktur lain yang digunakan API. 

Post-mortem pada API yang sudah dihentikan dapat menjadi latihan yang berguna. Tim dapat mendiskusikan pelajaran yang dipetik selama siklus hidup API lengkap dan bagaimana pelajaran tersebut dapat diterapkan pada proyek masa depan.