Jadi, Anda ingin menjadi yang pertama API? – Menuju AI — Publikasi AI dan Teknologi Terkemuka di Dunia

Penulis (s): Oryan Omer

Awalnya diterbitkan di Towards AI the World’s Leading AI and Technology News and Media Company. Jika Anda sedang membangun produk atau layanan terkait AI, kami mengundang Anda untuk mempertimbangkan untuk menjadi sponsor AI. Di Towards AI, kami membantu menskalakan AI dan startup teknologi. Biarkan kami membantu Anda melepaskan teknologi Anda kepada massa.

Rekayasa Perangkat Lunak

Memutuskan untuk menjadi produk API-first bukanlah keputusan sepele yang harus dibuat oleh sebuah perusahaan. Perlu ada keselarasan mendalam di seluruh perusahaan, mulai dari R&D hingga pemasaran, tentang mengapa dan bagaimana pendekatan API-first akan mempercepat pengembangan, go-to-market, dan bisnis pada umumnya. Tetapi yang lebih penting, sama seperti Anda membutuhkan kecocokan pasar-produk, Anda membutuhkan kecocokan API-pasar-produk. Ada perbedaan besar antara mengeksternalisasi API dan menjadi yang mengutamakan API, dan bergantung pada klien Anda dan kasus penggunaannya, Anda harus memahami apakah API atau API-first adalah pilihan yang tepat untuk Anda.

Postingan ini membahas bagaimana API dan API-first berdampak pada bisnis dan R&D melalui evolusi yang kami alami di Superwise saat kami menjadi produk dan bisnis API-first.

API bukan hanya tentang kode

Untungnya kita tidak perlu masuk lebih dalam di sini. API sangat umum pada titik ini sehingga bahkan orang yang paling non-teknis dari bisnis tahu bahwa API adalah Antarmuka Pemrograman Aplikasi yang menstandarisasi komunikasi sehingga dua aplikasi dapat mengirim/menerima data antara satu sama lain. Masalah dengan ini adalah bahwa mereka sangat umum saat ini sehingga kadang-kadang Anda akan melihat bisnis mendorong API tanpa kesesuaian API produk dan/atau kematangan pengembangan produk yang kuat.

Haruskah API Anda menjadi warga negara kelas satu?

Anda perlu bertanya pada diri sendiri serangkaian kriteria sebelum memutuskan apa yang harus dilakukan terkait API; lakukan all-in dan jadilah API-first, ekspos satu set API, atau katakan tidak pada API secara keseluruhan. Tidak ada angka ajaib ya atau tidak di sini; Anda bahkan mungkin mengatakan ya untuk semua yang tercantum di bawah ini, dan tetap saja, API-first akan salah untuk produk/bisnis Anda.

Gambar yang lebih besar cocok

Hal pertama yang perlu Anda ketahui adalah di mana API Anda cocok dengan gambaran yang lebih besar dan seberapa integralnya itu untuk meningkatkan nilai.

Apakah solusi Anda merupakan bagian dari proses yang lebih ekstensif? Ya, pengguna cenderung merasa terganggu dengan banyaknya alat dan platform yang perlu mereka gunakan untuk melakukan pekerjaan mereka, tetapi ada perbedaan besar antara alat yang digunakan bulanan dan alat harian. Apakah mengkonsumsi solusi Anda melalui API menghasilkan nilai lebih bagi pengguna? BI adalah contoh yang sangat baik dari nilai yang lebih tinggi melalui API dengan membuat informasi dapat diakses oleh semua pemangku kepentingan dalam organisasi.

Lihatlah observabilitas model misalnya. Ini belum tentu merupakan alat sehari-hari, tetapi sangat penting untuk misi, dan ketika terjadi kesalahan dengan ML dalam produksi, pemantauan dapat memicu serangkaian proses apa pun untuk menyelesaikan anomali. Selain itu, hampir selalu, Anda juga harus memaparkan masalah kepada pemangku kepentingan lain dalam organisasi sehingga mereka dapat mengambil tindakan pencegahan hingga akar masalahnya terungkap dan insiden tersebut diselesaikan.

Dapat digunakan kembali secara konsisten

Jadi Anda memiliki gambaran besar yang pas, dan API Anda menciptakan nilai tambah bagi pengguna Anda; fantastis. Sekarang pikirkan tentang bagaimana pengguna Anda menggunakan produk Anda dan apakah ini diterjemahkan secara konsisten, di seluruh basis pengguna Anda, ke penggunaan API.

Apakah kecocokan pasar produk Anda ada di mana-mana? Apakah sebagian besar pengguna Anda ingin menggunakan API kurang lebih dengan cara yang sama? Login sosial adalah contoh yang sangat baik dari API-first. Ini adalah produk dengan reusability yang konsisten di seluruh basis pengguna. Dapatkah organisasi mana pun mengimplementasikan API Anda? Ini tentang kedua titik akhir, bukan hanya API Anda. Jika sistem yang biasanya Anda integrasikan adalah niche atau memerlukan pengetahuan domain tertentu, mungkin tidak semua organisasi akan menerima API Anda karena mereka tidak memiliki sumber daya yang diperlukan untuk memasukkannya ke dalam proses mereka. Apakah pengguna Anda memerlukan API atau semua API? Apakah sepadan dengan waktu dan upaya Anda untuk menggunakan API terlebih dahulu, atau apakah Anda akan mendapatkan dampak yang sama dengan satu atau dua API dalam pendekatan yang tidak mengutamakan API?

Perjalanan Superwise ke API-first

Sejujurnya, ketika kami pertama kali mulai mengekspos API, kami tidak memiliki proses yang kuat, apalagi mentalitas yang mengutamakan API. Kami mengekspos beberapa API, beberapa untuk penggunaan internal di aplikasi web kami dan beberapa untuk konsumsi pelanggan langsung. Sulit untuk memelihara API dan dokumentasinya, dan kami tidak memiliki alur untuk menangani masuknya permintaan pelanggan untuk mengubah / membuat API. Selain itu, dan mungkin yang paling penting, karena kami tidak memiliki proses dan pola pikir yang terdefinisi dengan baik, ada banyak miskomunikasi dan ‘kehilangan momen penerjemahan antara tim backend dan frontend kami yang mengakibatkan, lebih sering daripada yang saya inginkan. untuk mengakui, dalam bug dan over-mengambil.

Semua masalah yang berasal dari API ini membuat kami duduk dan berpikir tentang apa yang tepat bagi kami terkait API dan bagaimana membangun proses yang memfasilitasi skala, baik milik kami maupun pelanggan kami, tanpa masalah yang kami alami hingga saat ini. Hasilnya terlihat dari judul postingan ini; kami memutuskan untuk menggunakan API terlebih dahulu.

Jadi apa yang kami lakukan?

API adalah masalah besar bagi pelanggan kami, internal dan eksternal, dan produk kami bergantung pada kualitas API kami dan kemampuannya untuk memberikan nilai dengan mulus.

Siapa kliennya? Intern? Luar? Apakah permintaan dan respons API selaras dan sesuai dengan kasus penggunaan klien? Anda perlu menemukan keseimbangan antara meminimalkan panggilan API dan pemanggilan secara eksplisit. Terlalu banyak panggilan API tidak efisien, tetapi pemanggilan yang membingungkan tidak efektif — keduanya merugikan pengalaman pengguna.

Setelah kami mengetahui semua ini, kami mendokumentasikan API kami untuk membuat “konstruksi” tentang bagaimana API akan dikonsumsi. Ini memberi tim frontend kami kemampuan untuk meniru data dan terus mengembangkan fitur frontend tanpa menunggu dukungan dari backend. Cara berpikir tentang API kami sebagai bagian integral dari produk ini membuat kami selalu memeriksa setiap permintaan untuk memastikan bahwa API kami tetap dapat digunakan kembali dan fleksibel.

Keuntungan menggunakan API-first

Menjadi yang mengutamakan API, baik secara teknis maupun dalam hal pola pikir, memiliki dampak yang kuat pada kemampuan kami untuk menskalakan aplikasi dan berintegrasi dengan layanan eksternal dengan cepat. Sebelum kami mulai berpikir tentang API kami sebagai warga kelas satu ketika kami memuat API tertentu, tidak mungkin untuk menskalakan API khusus itu saja; kami harus menskalakan semua aplikasi kami. Dengan beralih ke API-first, semua API kami dirancang untuk layanan mikro dengan tugas tertentu. Hal ini memungkinkan kami untuk menskalakan setiap API sesuai dengan bebannya dan menjadi efisien dengan sumber daya kami.

Minimalkan dependensi — Pola pikir yang mengutamakan API membawa dependensi ke garis depan dan mendorong kami untuk memisahkan API berdasarkan desain sehingga pembaruan/perubahan dapat dilakukan pada level API dan bukan pada level aplikasi, yang memengaruhi semua API. Ini tidak selalu dapat dicapai, tetapi jika memungkinkan, memutakhirkan/mengubah API akan menjadi tugas yang lebih mudah dan mandiri. Parallelize development — Tim pengembangan dapat bekerja secara paralel dengan membuat kontrak (yaitu: mendokumentasikan rute API Anda, permintaan, tanggapan) antar layanan tentang bagaimana data akan diekspos. Dengan cara ini, pengembang tidak perlu menunggu pembaruan untuk API dirilis sebelum beralih ke API berikutnya, dan tim dapat mengolok-olok API dan menguji dependensi API berdasarkan definisi API yang ditetapkan. Percepat siklus pengembangan — API-first berarti kami mendesain API kami sebelum coding. Umpan balik awal pada desain memungkinkan tim untuk beradaptasi dengan masukan baru sementara biaya perubahan masih relatif rendah, mengurangi biaya keseluruhan selama masa proyek. QA dalam desain — gandakan pada fase desain karena memperbaiki masalah setelah API dikodekan membutuhkan biaya lebih banyak daripada memperbaikinya selama fase desain. Desain untuk dapat digunakan kembali — Anda juga dapat mengurangi biaya pengembangan dengan menggunakan kembali komponen di beberapa proyek API.

Poin-poin penting untuk menjadi API-first

Menerapkan pendekatan pengembangan yang mengutamakan API di organisasi Anda memerlukan perencanaan, kerja sama, dan penegakan. Berikut adalah beberapa poin dan konsep kunci untuk dimasukkan ke dalam strategi API-first Anda untuk memastikannya sukses:

Dapatkan umpan balik awal — Memahami siapa klien API Anda, di dalam dan di luar organisasi Anda, dan mendapatkan umpan balik awal tentang desain API membantu Anda memastikan kesesuaian kasus penggunaan API. Ini akan membuat API lebih mudah digunakan dan mempersingkat siklus pengembangan Anda. Selalu desain terlebih dahulu — API (desain)-pertama berarti Anda menjelaskan setiap desain API dengan cara berulang yang dapat dipahami oleh manusia dan komputer — sebelum Anda menulis kode apa pun. Konsumsi API adalah bagian dari proses desain, dan penting untuk diingat bahwa klien (dalam bentuk jamak) akan berinteraksi dengan fitur melalui API, jadi Anda harus selalu mengingat semua orang dan tidak terlalu fokus pada klien tertentu. Mempertimbangkan desain terlebih dahulu juga akan memudahkan untuk memahami semua dependensi dalam tugas. Dokumentasikan API Anda — Dokumentasi API adalah suatu keharusan karena membuat konstruksi antara klien dan pengembang. Dokumentasi sangat penting untuk memastikan bahwa konsumsi API efektif dan efisien. Kami ingin tepat dalam bahasa dan contoh, sehingga klien mendapatkan dampak maksimal dengan upaya minimal. Otomatiskan proses Anda — Gunakan alat seperti SwaggerHub untuk mengotomatiskan proses seperti membuat dokumentasi API, validasi gaya, tiruan API, dan pembuatan versi. Permudah untuk memulai — Sediakan dokumentasi dan kotak pasir interaktif sehingga pengembang dapat mencoba titik akhir API dan segera mulai membuat aplikasi dengan API Anda.

Banyak yang telah dikatakan tentang menggunakan API terlebih dahulu, dan ada banyak sumber daya dan praktik terbaik (misalnya, artikel ini dari Auth0 dan Swagger) yang dapat membantu Anda melalui transisi. Tetapi menggunakan API-first tidak selalu memerlukan refactoring aplikasi Anda yang sudah ada; ini tentang merangkul pola pikir yang berbeda. Bagi kami, tidak diragukan lagi ini adalah jalan yang benar untuk diambil, kami melihatnya dalam kepuasan pelanggan dan peningkatan penggunaan, dan kami melihatnya dalam cara kami menskalakan lebih cepat dan lebih efisien, dan kami melihatnya dalam cara kami mengembangkan dan menerapkan yang baru. kemampuan lebih cepat kepada pelanggan kami.

Jadi, Anda ingin menjadi yang pertama API? awalnya diterbitkan di Towards AI on Medium, di mana orang-orang melanjutkan percakapan dengan menyoroti dan menanggapi cerita ini.

Diterbitkan melalui Menuju AI