Apa itu model kematangan API?

Beberapa kerangka kerja kematangan API menekankan dimensi tertentu seperti keamanan, kemudahan ditemukan, pemeliharaan, atau rekayasa platform. Vendor API Management, termasuk Kong, Tyk, dan Curity, menawarkan model kematangan API yang selaras dengan solusi mereka sendiri, membantu klien mengukur kemajuan mereka dalam mengadopsi platform tersebut. Model lain lebih luas cakupannya dan dapat diterapkan pada protokol atau arsitektur apa pun.

Antarmuka pemrograman aplikasi (API), yang memfasilitasi koneksi antara layanan dan aplikasi terpisah, adalah pilar utama internet, membantu pengembang menggunakan teknologi pihak ketiga dan sumber data, alih-alih membangunnya dari awal. API juga memungkinkan integrasi sumber daya, data, keamanan dan tata kelola di dalam organisasi, merampingkan penerapan internal dan komunikasi lintas tim. Beberapa API dapat dikemas bersama pustaka, alat UI, dan komponen lainnya untuk membentuk kit pengembangan perangkat lunak (SDK), seperangkat alat yang membantu pengembang membangun aplikasi standar dengan cepat dan andal.

Model kematangan API mengidentifikasi dan menggambarkan inovasi struktural dan teknologi tertentu serta praktik terbaik strategis yang dapat membantu organisasi mengembangkan sistem API yang lebih canggih dan kuat, meningkatkan efisiensi, keamanan, dan interoperabilitas. Mereka berfungsi sebagai peta jalan yang membantu organisasi memutuskan inovasi mana yang harus diprioritaskan saat mereka mempercepat pengembangan API mereka.

Model kematangan Richardson, salah satu kerangka kerja yang paling banyak dikutip, menilai kepatuhan API terhadap prinsip-prinsip RESTful di empat tingkat kematangan, dengan tingkat tertinggi mewakili sistem RESTful sepenuhnya.

Pada tahun 2000, ilmuwan komputer Roy Fielding memperkenalkan REST, gaya arsitektur yang mempromosikan fitur-fitur seperti antarmuka yang seragam, pemisahan klien-server, statelessness, kemampuan caching, dan sistem berlapis. Bersama-sama, kemampuan ini dapat meningkatkan skalabilitas, efisiensi, dan fleksibilitas dalam organisasi dan dapat berkontribusi pada internet yang lebih terbuka, tangguh, dan aman ketika diterapkan pada skala yang lebih besar. Iterasi modern sering menggunakan HTTP untuk mengangkut informasi dan format JSON yang dapat dibaca manusia untuk mengatur data ini, meskipun protokol dan format lain juga dapat digunakan.

Pada tahun 2008, insinyur perangkat lunak Leonard Richardson membangun kerangka kerja ini dengan model yang mengidentifikasi perubahan teknis spesifik yang dapat diterapkan organisasi untuk meningkatkan kemampuan beradaptasi dan ketahanan desain REST API mereka. Model kematangan Richardson (RMM) “mendorong Anda untuk melihat tiga teknologi web—URI, HTTP, dan hypermedia (juga dikenal sebagai HTML)—sebagai tiga teknologi individual daripada penawaran sepaket”, kata Richardson kepada IBM Think. Kerangka kerja ini menunjukkan manfaat praktis dari penerapan masing-masing secara bertahap, "mengingat kami memiliki teknologi ini, mereka sangat populer, didukung secara luas oleh setiap bahasa pemrograman."

Model kematangan Richardson memprioritaskan implementasi sumber daya, di mana setiap sumber daya diberi URI yang berbeda, sesuai dengan prinsip REST umum, yang merekomendasikan untuk menetapkan setiap sumber daya identifikasi unik. RMM juga mendorong penggunaan dokumen respons, yang menangkap status API saat ini, daripada dokumen deskripsi, yang menyajikan deskripsi statis dan telah ditentukan sebelumnya dari API pada satu titik waktu. Model ini umumnya berlaku untuk aplikasi web berbasis http, meskipun sebagai kerangka kerja, model ini juga dapat digunakan dalam konteks lain, seperti jaringan IoT dan pipeline data.

Model kematangan Richardson menggunakan empat tingkat untuk membedakan antara tingkat kematangan yang berbeda, dari arsitektur non-RESTful hingga arsitektur yang sepenuhnya RESTful.

Level nol mewakili desain non-RESTful, memiliki fitur titik akhir tunggal (seperti “/api”) dan perintah tunggal (biasanya POST). Meskipun level nol mudah diimplementasikan, level ini gagal menggunakan fitur HTTP yang paling kuat, termasuk kata kerja, URI, dan kode status. Sebagai gantinya, HTTP digunakan hanya sebagai mekanisme transportasi, dengan semua detail operasional ditambahkan ke badan pesan itu sendiri.

Karena pola panggilan prosedur jarak jauh (RPC) berbasis XML secara historis menggunakan metode ini, para kritikus menjulukinya “rawa POX” (XML lama biasa). Idenya adalah bahwa, dengan kurangnya struktur dan tidak ada penggambaran yang jelas antara layanan, fungsi dan data dapat dengan mudah menjadi berantakan dan digabungkan erat. Pada level nol, API tidak memiliki kapasitas untuk mengidentifikasi atau mengekspos sumber daya yang dapat ditemukan, memaksa konsumen API untuk mengetahui terlebih dahulu apa yang tersedia. Pengembang mungkin kesulitan dengan penskalaan, penerapan versi, dan pemecahan masalah karena titik akhir tunggal tidak dapat berbagi informasi tentang dirinya sendiri.

Level satu memperkenalkan beberapa URI, masing-masing mampu mewakili sumber daya yang berbeda. Tetapi level ini terus menggunakan hanya satu kata kerja HTTP, biasanya POST. Alih-alih berinteraksi dengan titik akhir “/api” generik, klien sekarang dapat memanggil titik akhir yang sesuai dengan sumber daya tertentu—misalnya, “/products,” “/carts” atau “/faktur” dalam pengaturan e-commerce. Namun, klien biasanya masih perlu menyampaikan maksud operasional atau tindakan melalui isi permintaan itu sendiri, daripada menggunakan set kata kerja HTTP yang telah ditentukan sebelumnya.

Pendekatan ini menetapkan batas yang lebih jelas antara sumber daya dan mengurangi ambiguitas terkait sumber daya yang tersedia untuk klien. Tetapi pengembang dapat dengan mudah bingung dengan tindakan mana yang dapat dilakukan karena tidak ada format standar untuk memanggil URI. Level satu juga bisa menjadi rumit dari waktu ke waktu karena, dalam praktiknya, pengembang mungkin membuat titik akhir baru untuk masing-masing tindakan, seperti “/ProductsUpdate” atau “/productsDelete.” Pendekatan ini dapat menyebabkan URI menumpuk secara bertahap, menyulitkan peluncuran dan pembuatan versi.

Akhirnya, model membuat pengembang lebih bergantung pada dokumentasi API eksternal karena, meskipun sumber daya diberi URI yang berbeda, mereka tidak dapat mengekspos tindakan mana yang dapat ditafsirkan atau dipenuhi.

Level dua menambahkan metode HTTP, seperangkat kata kerja standar yang dapat digunakan pengembang untuk berinteraksi dengan data dan layanan. Dalam banyak konfigurasi, klien dapat menggunakan empat perintah dasar—create (buat), read (baca), update (perbarui), atau delete (hapus)—untuk melakukan tindakan yang berbeda di setiap titik akhir. Header dapat digunakan untuk menyampaikan informasi tambahan—seperti jenis konten, persyaratan bersyarat, atau kredensial—selama panggilan API.

Pendekatan ini lebih efisien dan terorganisir dibandingkan dengan level satu dan level nol karena pengguna memiliki pemahaman tentang kemampuan API dan bagaimana klien dapat berinteraksi dengannya. Tetapi API tidak dapat menyampaikan informasi ini secara real time—pengguna hanya dapat mempelajari tentang setiap API melalui portal pengembang eksternal—sehingga mengurangi kemampuan untuk ditemukan. Pendekatan statis ini juga dapat menyebabkan ketidakselarasan jika dokumentasi API tidak cocok dengan kemampuan saat ini.

Saat ini, ekosistem API di sebagian besar organisasi beroperasi pada tingkat dua karena tingkat menawarkan keseimbangan antara prediktabilitas, efisiensi, dan aksesibilitas. Level ini juga memungkinkan organisasi untuk memanfaatkan kemampuan infrastruktur HTTP yang berbeda, seperti caching (menyimpan sumber daya yang sering digunakan secara lokal, sehingga dapat dengan cepat diambil), yang menghasilkan peningkatan kinerja yang signifikan.

Level tiga memperkenalkan HATEOAS, atau hypermedia sebagai mesin status aplikasi. Ketika klien membuat panggilan API, API akan merespons dengan daftar opsi dinamis untuk berbagai tindakan dan istilah terkait, seperti cara browser modern beroperasi. Tindakan dan istilah ini disampaikan secara in-band, yang berarti pengembang tidak perlu membaca dokumentasi eksternal untuk mempelajarinya. Arsitektur berbasis Hypermedia juga mendorong interoperabilitas karena klien eksternal dapat dengan mudah mengakses layanan tanpa mempelajari cara menggunakannya terlebih dahulu.

Pada saat yang sama, kontrol hypermedia memperkenalkan kompleksitas yang lebih besar pada waktu aktif: “Klien harus dapat tidak hanya bereaksi dengan cara yang telah diprogram sebelumnya tetapi dapat membaca dokumen yang masuk dari server dan menggunakan konten dokumen tersebut untuk membuat keputusan tentang permintaan berikutnya,” kata Richardson.

Membangun dan memelihara kemampuan hypermedia bisa lebih mahal dan memakan waktu karena struktur dinamis hypermedia. API menanggapi permintaan klien dengan serangkaian tautan untuk tindakan lebih lanjut, yang lebih membebani secara operasional. Selain itu, banyak platform klien tidak mendukung hypermedia, jadi ketika organisasi menggunakan HATEOAS, pengguna eksternal mungkin harus menemukan alat yang kompatibel sebelum mereka dapat mengakses layanan ini.

Saat ini, HATEOAS paling sering digunakan oleh perpustakaan, organisasi nirlaba, lembaga ilmiah, koalisi pasar, atau perusahaan pemberontak (organisasi yang mencoba menimbulkan disrupsi industri), kata Richardson, karena mendorong keterbukaan dan interoperabilitas. Hypermedia juga dapat efektif bila digunakan secara internal karena membuat API dan tindakan mudah ditemukan oleh pengguna, bahkan pengguna yang tidak memiliki pengetahuan sebelumnya tentang ekosistem API. Beberapa perusahaan mungkin menawarkan API hypermedia selama fase pertumbuhan mereka, dan kemudian membatasi akses setelah mereka mulai memonetisasi produk mereka.

Industri ini makin beralih ke alternatif seperti GraphQL dan gRPC untuk contoh penggunaan tertentu. Sementara 93% pengembang mengatakan mereka menggunakan layanan web RESTful dalam beberapa kapasitas, menurut laporan State of the API Postman, sepertiga sekarang menggunakan GraphQL dan 14% menggunakan gRPC. GraphQL dapat secara cerdas mengambil permintaan dari beberapa layanan mikro, bahkan layanan yang dihosting di lingkungan yang berbeda, dan mengompilasinya menjadi satu respons, meningkatkan efisiensi dan mencegah penyediaan yang berlebihan atau kurang. Sementara itu, gRPC ideal untuk streaming, telemetri, dan contoh penggunaan lainnya di mana kinerja tinggi dan latensi rendah adalah perhatian utama.

Sementara GraphQL dan gRPC tidak dapat mereplikasi sifat dinamis hypermedia, kedua arsitektur mengatasi masalah yang terkait dengan efisiensi dan manajemen skema dengan lebih presisi, menyebabkan beberapa organisasi memprioritaskan implementasi ini daripada kontrol hypermedia penuh.

Dalam model kematangan Richardson, berpindah dari satu tingkat kematangan API ke tingkat berikutnya dapat menghadirkan tantangan desain dan teknis. Proses ini sering melibatkan perombakan (refactoring) kode server untuk mengakomodasi beberapa URI (level satu) dan beberapa metode HTTP (level dua). Hal ini dicapai dengan memperbarui aturan routing, interaksi database, pengujian, dokumentasi, dan pengontrol.

Organisasi mungkin mulai dengan membuat katalog titik akhir mereka saat ini, mengidentifikasi titik akhir mana yang dapat dimodifikasi untuk mengikuti batasan RESTful, dan memetakan sumber daya dan kata kerja yang diperlukan. Pengembang dapat membangun versi baru berbasis build organisasi saat ini sehingga panggilan klien tidak terganggu selama transisi. Kumpulan kode kesalahan yang komprehensif juga dapat membantu pengguna mempelajari cara mengelola titik akhir API baru dan memecahkan masalah kesalahan tanpa membaca banyak dokumentasi.

Sementara RMM berfokus pada implementasi teknologi spesifik dalam sistem RESTful, model organisasi mengambil pandangan yang lebih luas, membantu perusahaan menyelaraskan seperangkat prinsip bersama yang mendorong konsistensi, optimalisasi sumber daya, dan kemampuan beradaptasi. Sementara kerangka kematangan strategis dapat berbeda menurut organisasi, satu pendekatan umum menggabungkan empat tingkatan:

Dalam ekosistem API dasar atau ad hoc, organisasi bereaksi terhadap masalah langsung daripada bekerja di bawah kerangka pengembangan API yang kohesif. Pengembang membuat dan menghentikan API sesuai kebutuhan dengan kontrol terpusat terbatas, yang dapat menyebabkan ketidakselarasan serta masalah tata kelola, keamanan, dan observabilitas. Dengan sedikit insight tentang kinerja API saat ini, tim tidak dapat mengalokasikan sumber daya atau merencanakan masa depan secara efektif.

Ekosistem API standar memiliki dokumentasi yang konsisten, konvensi penamaan, kode kesalahan, dan pola desain. Sebuah API Gateway mungkin digunakan untuk menerapkan autentikasi, otorisasi, dan protokol keamanan API terpusat lainnya. Pengembang dapat dengan percaya diri menambahkan, menghapus, dan memelihara API dalam struktur tata kelola organisasi dan dapat menggunakan kembali dan menyesuaikan komponen dengan lancar. Klien dapat dengan mudah menemukan dan mempelajari tentang layanan yang tersedia melalui portal pengembang dan orientasi terintegrasi, sehingga meningkatkan adopsi API secara keseluruhan.

Tetapi karena ada beberapa mekanisme untuk mencatat kinerja dan keamanan API pada tahap ini, tim mungkin kesulitan untuk mempertahankan pengawasan atas ekosistem. Misalnya, organisasi mungkin tidak menyadari pelanggaran keamanan, kesalahan pembuatan versi, atau masalah autentikasi dalam klaster API tertentu.

Kerangka kerja yang dikelola menggunakan data telemetri, KPI, dan metrik lainnya untuk mencatat kinerja API secara lebih terperinci. Misalnya, sistem pemantauan dapat memperingatkan pengembang ketika klien menghadapi waktu henti API yang berlebihan dan membantu mengidentifikasi masalah yang mendasarinya—apakah kelebihan beban server, pemadaman jaringan, ketidakselarasan kode, atau masalah lain.

Ekosistem yang dikelola mungkin juga memiliki infrastruktur tata kelola API yang lebih canggih, yang menjaga otonomi tim sambil memberikan pemahaman yang jelas kepada pemangku kepentingan tentang API mana yang pengelolaannya menjadi tanggung jawab mereka. Terakhir, ekosistem yang dikelola memperkenalkan proses manajemen siklus hidup formal, di mana API dipantau pada tahap desain, pengembangan, pemeliharaan, pembuatan versi, dan penghentian. Tetapi pada tingkat ini, organisasi mungkin masih belum memiliki visi pengelolaan API yang kohesif tentang bagaimana API Management berkontribusi pada tujuan bisnis yang lebih luas.

Kerangka kerja yang dioptimalkan atau strategis menggabungkan tata kelola, standardisasi, manajemen siklus hidup, metrik, dan praktik terbaik keamanan dengan perencanaan bisnis jangka panjang. Dengan pengawasan atas seluruh jaringan, organisasi dapat secara efisien menskalakan dan mengalokasikan sumber daya dan secara dinamis merespons perubahan kondisi pasar. Alih-alih menganggap API hanya sebagai komponen teknis, organisasi dapat menerapkan API untuk melayani tujuan bisnis yang lebih luas. Kerangka kerja strategis membantu organisasi menyusun peta jalan dan strategi perencanaan yang berorientasi masa depan, mempercepat inovasi, dan meningkatkan efisiensi operasional.

Organisasi mungkin membuat model kematangan API untuk mengatasi masalah tertentu atau fokus operasional. Area fokus umum meliputi:

Model kematangan ini berfokus pada prinsip-prinsip desain API seperti mengadopsi protokol, praktik, dan standar tertentu yang berkontribusi pada peningkatan pengalaman pengguna. RMM adalah salah satu contoh kerangka kerja berbasis desain, tetapi model lain mungkin fokus pada GraphQL, gRPC, dan gaya arsitektur lainnya.

Model tata kelola berfokus pada sejauh mana organisasi dapat mempertahankan kontrol dan pengawasan atas ekosistem API mereka. Pada tingkat tertinggi, organisasi mempertahankan kepatuhan, kualitas data, dan keamanan yang tinggi sambil menjaga otonomi pemangku kepentingan.

Kerangka kerja berbasis tata kelola juga mempertimbangkan kualitas mekanisme penegakan dari suatu ekosistem API, termasuk apakah mekanisme ini menggabungkan pemeriksaan otomatis dan proses validasi. Sementara itu, model kepemilikan menetapkan API ke tim tertentu sehingga setiap API diperhitungkan.

Kerangka kerja yang berfokus pada keamanan menilai kepatuhan jaringan API terhadap praktik terbaik keamanan. Pada tahap awal, organisasi mungkin mengandalkan kunci API atau autentikasi HTTP dasar, yang keduanya tidak memiliki kontrol granular dan rentan terhadap pengungkapan. Sistem tingkat lanjut mungkin memperkenalkan autentikasi dan otorisasi berbasis token serta akses zero-trust. Kerangka kerja yang paling canggih mematuhi prinsip-prinsip manajemen identitas dan akses, seperti menggunakan protokol otorisasi OAuth dan OpenID Connect (OIDC).

Dokumen API adalah panduan teknis yang memberikan instruksi tentang bagaimana pengembang dapat menggunakan dan mengintegrasikan API tertentu. Dokumentasi dapat mencakup tutorial dan contoh kode serta catatan rilis dan parameter panggilan yang dapat diterima.

Awalnya, organisasi mungkin tidak memiliki proses standar untuk membuat dan memelihara dokumentasi API, memberi pengembang sedikit insight tentang kemampuan masing-masing API. Tingkat yang lebih tinggi mungkin memperkenalkan format standar untuk menjelaskan spesifikasi API, seperti OpenAPI Specification (OAS) atau cetak biru API. Kerangka kerja API yang matang mungkin juga menggabungkan otomatisasi, membantu memastikan bahwa dokumentasi diperbarui secara otomatis bersama setiap peluncuran.

Model kematangan yang berfokus pada observabilitas membantu organisasi melacak kecanggihan mekanisme pengumpulan data mereka di seluruh layanan mikro. Sistem dasar mungkin menggunakan telemetri dan metrik untuk membantu organisasi menemukan kesalahan tetapi tidak dapat membantu mengidentifikasi tren data jangka panjang.

Platform yang lebih kompleks dapat secara proaktif melacak latensi, tingkat permintaan, dan metrik relevan lainnya untuk membantu organisasi merespons waktu henti, ketidakselarasan, dan masalah lainnya sebelumnya. Di tingkat tertinggi, organisasi dapat mengidentifikasi pola data tingkat tinggi dan menghasilkan insight yang dapat ditindaklanjuti untuk memandu pengembangan API di masa depan.