Layanan Mikro, API dan Inovasi: Kekuatan API

Halo semuanya!



Hari ini kami ingin menawarkan terjemahan sebuah artikel pemrograman kepada Anda oleh Mike Amundsen , arsitek utama di API Academy. Dalam teks yang relatif singkat ini, Mike menjelaskan secara cerdas mengapa Anda perlu memberi perhatian khusus pada pengembangan API, dan bagaimana API dilakukan dengan benar.

Selama menjadi guru di Akademi API, saya berkesempatan berkeliling dunia bertemu orang-orang hebat. Mereka mengerjakan proyek-proyek menakjubkan di berbagai perusahaan - dari startup muda hingga perusahaan global yang sudah mapan. Luar biasa, tetapi di mana pun saya berada dan dengan siapa saya berbicara, banyak ide, trik, dan kesan umum muncul dalam percakapan kami. Tiga yang paling umum adalah layanan mikro, API, dan budaya inovasi. Ketiganya diperkenalkan untuk mempercepat transformasi digital organisasi.

Artikel ini adalah yang kedua dari serangkaian tiga publikasi. Di sini saya akan berbicara tentang apa yang kami ajarkan di akademi API kami dalam konteks tiga tren yang kuat ini, dan juga menjelaskan beberapa trik yang akan membantu perusahaan Anda beralih dari kata-kata besar ke konversi nyata. Dalam artikel sebelumnya, saya memberikan perhatian khusus pada pentingnya layanan-mikro dan memfokuskan pada tiga hal yang dapat Anda lakukan hari ini: 1) transisi ke pengiriman berkelanjutan, 2) penyediaan penyebaran yang disiapkan, dan 3) mengurangi antrian “dalam pekerjaan” untuk mengurangi waktu sebelum produk mencapai pasar. Tiga kebiasaan penting ini akan membantu organisasi Anda memanfaatkan sepenuhnya manfaat layanan mikro.

API menyediakan pengiriman multi-saluran

Banyak perusahaan menggunakan layanan-layanan mikro, mencoba merangkum kapabilitas kunci organisasi mereka sedemikian rupa untuk memastikan skalabilitas dan keandalannya. Layanan Microsoft berhubungan dengan elemen fungsional penting dari komponen TI perusahaan Anda. Tapi ini baru setengah pertempuran. Penting juga untuk mencari cara menyediakan peluang ini, sehingga dengan bantuan mereka akan lebih mudah untuk menyelesaikan tantangan saat ini yang dihadapi bisnis Anda. Di sinilah API berperan.

API - antarmuka pemrograman aplikasi - memainkan peran yang sama untuk mesin sebagai antarmuka grafis - untuk pengguna sistem informasi perusahaan Anda. Seringkali, API digunakan untuk menggabungkan berbagai kemampuan menjadi solusi yang konsisten dan terjangkau. Misalnya, perusahaan Anda dapat menggunakan layanan untuk memproses transaksi yang terkait dengan pelanggan, akun, dan penjualan. Masing-masing layanan ini dirancang, diprogram, diuji dengan cermat, setelah itu dirilis dan dimasukkan ke dalam infrastruktur perusahaan Anda; Layanan ini menyediakan fungsionalitas penting untuk bisnis Anda. Setelah Anda perlu membuat solusi baru untuk memperkenalkan pengguna ke hal-hal - dan solusi ini harus bekerja pada berbagai perangkat dan platform. Jadi, kami mulai menggunakan API dengan kapasitas penuh.

Satu API yang dipertajam untuk solusi - misalnya, API untuk mengakrabkan pengguna dengan sistem - dapat dirancang sehingga interaksi dan aliran tugas yang paling penting pada tahap sosialisasi seperti itu muncul ke permukaan. Di sini kami membutuhkan API yang memungkinkan Anda untuk mencampur berbagai elemen fungsional yang terkait dengan pelanggan, akun, dan penjualan menjadi antarmuka pengguna yang aman, kuat, dan terjangkau untuk berbagai macam audiens target di perusahaan Anda. Misalnya, orang-orang penjualan dapat masuk dari browser, admin kantor dari aplikasi PC, dan pelanggan potensial dari ponsel cerdas dan tablet.

Kita dapat mengatakan bahwa API adalah semacam "perekat" yang menyatukan elemen-elemen program, lapisan perantara di mana layanan internal Anda dan konsumen eksternal layanan berinteraksi. API adalah alat untuk mendistribusikan fungsionalitas utama sedemikian rupa sehingga konsumen layanan dapat menggunakannya, yang tugasnya adalah menciptakan mekanisme penting untuk berinteraksi dengan pengguna di berbagai platform perangkat keras. Konsumen tersebut dapat mencakup tim lain yang bekerja di kantor Anda, kolega yang Anda ajak berkomunikasi dari jarak jauh, mitra bisnis utama atau bahkan karyawan jarak jauh yang terlibat dalam pengembangan atau desain sisi klien.

Desain Berpikir dan API

Sebagian besar perusahaan tahu betapa pentingnya mencurahkan waktu untuk mengembangkan antarmuka pengguna untuk aplikasi mereka. Karena diketahui bahwa desain yang baik disukai oleh pengguna, meningkatkan loyalitas merek dan memungkinkan Anda untuk mempromosikan bisnis baru. Pada saat yang sama, desain antarmuka yang dirancang dengan buruk dapat mengganggu pelanggan, merusak merek, mengurangi pendapatan, dan memilih peluang. Hal yang sama berlaku untuk desain API.

Jika API dilakukan dengan buruk, maka akan sulit bagi pengembang untuk memahaminya, karena ini mereka dapat memasukkan kesalahan ke dalam sistem dan memicu pengeluaran yang tidak perlu untuk memperbaiki bug dan memodifikasi infrastruktur. Namun, jika API berfungsi dengan baik, maka lebih mudah bagi karyawan untuk bekerja secara efektif dengannya. Waktu yang diperlukan untuk membuat solusi stabil berkurang, tim bahkan mendapat insentif untuk mengeluarkan solusi baru dan inovatif yang akan membantu klien dan kolega. Desain API adalah area kerja yang sangat penting sehingga Werner Vogels, chief technology officer Amazon, bahkan mengatakan:

Kami segera menyadari bahwa merancang API adalah tugas yang sangat penting, karena kami hanya akan memiliki satu upaya untuk menyelesaikannya dengan benar.

Ini adalah API berkualitas tinggi yang membantu menarik mitra ke ekosistem digital Anda dan menyederhanakan transformasi internal bisnis Anda. Kemampuan untuk menghabiskan waktu untuk melakukan segalanya dengan benar, dan, dalam jangka panjang, adalah keterampilan penting yang kami lacak hanya dari perusahaan-perusahaan yang telah belajar cara memanfaatkan sepenuhnya API mereka.

Tips Desain API Penting

Sangat penting untuk membuat API menjadi benar - dan ada banyak alasan. Setelah rilis, tidak mungkin untuk memutar kembali API. Ketika pelanggan dan struktur bisnis utama bergantung pada API Anda, mengubah dependensi dapat merusak elemen-elemen lain dari sistem, merusak fungsionalitas penting, dan tidak membiayai investasi dan waktu yang dihabiskan. Saat menerapkan program API, Anda perlu mengingat hal-hal penting lainnya. Saya akan menyebutkan hanya beberapa.

API Canonical tidak ada

Adalah kesalahan untuk mencoba "di muka" untuk memilih desain API kanonik untuk seluruh perusahaan Anda. Hanya mencoba menerapkan beberapa objek dan model data di seluruh perusahaan, yaitu, mencoba membuat API tunggal yang akan memperhitungkan semua aspek organisasi Anda tanpa kecuali, sekarang dan di masa depan - kemungkinan besar ini adalah jalan buntu. Jauh lebih baik untuk memberikan rekomendasi kepada pengembang Anda dan menunjukkan batasan yang akan membantu mereka menghindari kesalahan, mengungkap secara kreatif, dan menerapkan pengetahuan domain untuk membuat API yang luar biasa yang akan menarik bagi kolega dan mitra.

Proses implementasi: memotong semua yang tidak perlu

Karena API hanyalah antarmuka, bukan fungsional seperti itu, Anda harus dapat merancang, mengimplementasikan, menguji, dan menggunakan API dalam hitungan hari dan minggu, tetapi tidak dalam hitungan bulan. Kami tahu bagaimana perusahaan berusaha mengurangi risiko membuat API, memastikan bahwa API nyaman untuk diuji di muka, mengotomatiskan proses rilis, sehingga API itu sendiri lebih murah dan lebih nyaman untuk dikomposisikan.

Fokus pada interaksi, bukan integrasi

Aspek kunci lain yang dapat diatasi oleh perusahaan yang sukses adalah kemampuan untuk mengajarkan tim pengembangan untuk berintegrasi ke dalam API kemampuan untuk berinteraksi dengan elemen lain yang sudah ada pada tahap desain. Organisasi semacam itu menjelaskan cara bekerja dengan API mereka, oleh karena itu, API seperti itu tidak hanya mudah dimengerti, tetapi juga mudah dihubungkan dengan API lain dari perusahaan ini. Berfokus pada interaksi luas lebih penting daripada merancang integrasi yang sempit dan ketat.

Tiga hal yang bisa Anda lakukan hari ini

Pekerjaan seperti itu, seperti halnya perubahan penting, membutuhkan waktu. Namun, tidak akan lama untuk menunggu kesuksesan. Saya akan memberi tahu Anda tentang tiga langkah yang harus saya amati di berbagai perusahaan, yang dapat Anda ambil hari ini.

Lakukan praktik API Anda sendiri

Komponen kunci keberhasilan jangka panjang program API Anda adalah mengembangkan praktik desain API khusus teknologi. Pastikan bahwa program seperti itu tidak akan sepenuhnya bergantung pada mode terbaru dalam pemrograman, menggunakan perpustakaan atau platform. Untuk ini, akan lebih mudah untuk mengandalkan paradigma "langkah pertama - API".

“Hal pertama adalah API” berarti bahwa kami pertama-tama merancang API, dan baru kemudian memikirkan detail penerapannya. Pada prinsipnya, komponen bisnis adalah sama terlepas dari teknologi apa yang Anda gunakan untuk mengimplementasikan API: apakah itu SOAP, CRUD, REST, gRPC, GraphQL atau hal populer lainnya. Bahkan, program yang dirancang dengan baik kemungkinan besar akan memungkinkan Anda untuk merumuskan rekomendasi yang relevan untuk tumpukan teknologi yang berbeda, masing-masing, membantu tim Anda dan mengevaluasi penghematan yang mungkin, dan menjaga keputusan yang konsisten pada versi platform masa depan.

Kami menjamin risiko rendah saat membuat API

Setelah merancang API dengan kualitas tinggi, saatnya untuk mengubahnya menjadi kenyataan. Pada saat yang sama, saya sarankan memulai dengan sketsa, kemudian beralih ke pola prototipe dan perakitan.

API Garis Besar justru merupakan "sketsa". Perkiraan "gambar" kecil yang membantu memberi kesan tentang bagaimana API ini bisa berubah "sesuai selera dan warna" dari posisi pengembang. Sketsa API harus dilakukan dalam beberapa jam, bukan hari. Selain itu, atas dasar itu, sebuah proyek harus diperoleh yang dapat ditunjukkan kepada kolega dan pemangku kepentingan sehingga diskusi putaran pertama dan modifikasi pertama hampir tanpa biaya. Saya suka menggunakan templat API Apiary untuk ini. Ini menggunakan bahasa markup sederhana yang memungkinkan Anda untuk mensimulasikan server API yang berfungsi dalam hitungan menit. Alat khusus tidak begitu penting, latihan itu penting. Garis besar membantu Anda melakukan riset murah, dan baru kemudian mulai menyiapkan API lengkap.

Saya perhatikan bahwa ketika membuat prototipe, alat-alat seperti Swagger / OpenAPI populer. Prototipe adalah model yang jauh lebih rumit dari produk akhir Anda. Mereka mirip dengan pemandangan untuk film ini. Jika Anda tidak melihat dari dekat, Anda melihat pemandangan yang sebenarnya nyata! Tim harus dapat menyiapkan prototipe terperinci hanya dalam beberapa hari. Prototipe semacam itu harus secara bebas terhubung ke instrumen uji, layanan virtualisasi, dan elemen platform lainnya sehingga Anda dapat secara langsung mengamati bagaimana berinteraksi dengan sistem Anda. Prototipe diperlukan untuk mengujinya. Mereka adalah garis pertahanan terakhir Anda sebelum Anda harus mengeluarkan uang untuk membuat API yang berfungsi nyata.

Di sini fase perakitan selesai. Selanjutnya, kita harus merumuskan rencana kerja, menetapkan tenggat waktu dan mulai mengubah prototipe menjadi produk. Kami membutuhkan sketsa dan prototipe untuk mengerjakan perincian, mengidentifikasi bug, dll. Proses pembuatannya sendiri tidak begitu menarik. Anda hanya perlu menunjukkan hasil yang sudah selesai setiap hari, selangkah demi selangkah mengimplementasikan API sampai pekerjaan siap. Banyak perusahaan berusaha untuk membangun API tidak lebih dari 90 hari.

API manajemen tiga paus

Terakhir, jika Anda mempertimbangkan situasinya secara lebih luas daripada pada tingkat desain dan implementasi API tertentu, Anda harus mematuhi program yang layak untuk bekerja dengan API di organisasi Anda dan menerapkan rekomendasi umum untuk mengembangkan API yang akan diketahui oleh semua tim. Regulasi yang jelas memungkinkan Anda untuk mengontrol pengembangan API di seluruh perusahaan, tanpa harus melakukan pengawasan berlebihan atas detail implementasi.
Eric Wilde, kolega saya di API Academy, menekankan pentingnya “mengelola lanskap API Anda,” yaitu, mengatur tiga elemen kunci dari program API: protokol, format, dan terminologi.

Regulasi protokol adalah indikasi yang jelas tentang protokol level aplikasi mana yang harus didukung oleh tim API saat menyiapkan rilis baru. Sebagian besar perusahaan percaya bahwa semua API baru harus mendukung HTTP. Beberapa juga menunjukkan protokol opsional lain, seperti MQTT, Thrift, dan protokol biner lainnya. Di sini, sangat penting untuk memberi tahu semua tim terlebih dahulu: "Jika Anda ingin menjamin interoperabilitas API Anda di masa mendatang, Anda harus menggunakan protokol ini." Untuk menerapkan aturan ini, disarankan untuk menggunakan pipa pengiriman kontinu.

Regulasi format berarti Anda harus menyetujui format apa yang akan dikirim data antar layanan. Hampir semua browser mengharapkan respons dalam format HTML - begitu saja, di tingkat API Anda, Anda perlu memutuskan format apa yang akan berinteraksi dengan seluruh ekosistem. Sebagian besar perusahaan lebih suka format sederhana, seperti JSON, XML, atau CSV, tetapi model pesan mereka tidak memiliki metadata kunci, khususnya nama objek, tautan, dan formulir input - dan mereka diperlukan untuk interaksi jangka panjang. Di sisi lain, saya juga tahu perusahaan yang menggunakan format yang lebih maju, misalnya, HAL, Siren, dan Collection + JSON untuk API berbasis HTTP. Untuk interaksi biner antara layanan, banyak organisasi mengambil protobuf dan format serupa sebagai dasar. Terlepas dari format apa yang Anda pilih, penting untuk memeriksanya di jalur perakitan Anda, memastikan bahwa hanya API yang sepenuhnya mematuhi peraturan yang akan diproduksi.

Kit manajemen API ketiga adalah terminologi. Dalam hal ini, kita berbicara tentang kontrol atas nama titik data dan pengidentifikasi tindakan yang digunakan saat bertukar pesan antar layanan. Mengikuti terminologi, organisasi mungkin tidak ragu bahwa layanan baru akan secara normal diterima oleh yang sudah ada. Mengingat "bahasa umum" yang diusulkan oleh Eric Evans untuk desain berorientasi subjek (DDD), saya perhatikan bahwa terminologi yang Anda pilih diperlukan untuk berbicara tentang operasi bisnis yang paling kritis. Seharusnya sulit untuk menghasilkan layanan dalam produksi yang menggunakan nama "baru" untuk bidang data dan pengidentifikasi tindakan. Sebaliknya, elemen-elemen dari jalur perakitan harus diperiksa untuk kesesuaian dengan terminologi umum yang diterima di seluruh perusahaan, dan API yang keluar dari terminologi ini tidak boleh masuk dalam produksi.

Setelah mempelajari prinsip-prinsip ini: "Pertama-tama - API", "sketsa-prototipe-perakitan" dan "tiga kit kontrol API", tim Anda akan dapat menggunakan API mereka pada kapasitas penuh, tanpa risiko stabilitas mereka selama eksekusi.