API MySklad pertama muncul 10 tahun lalu. Selama ini kami mengerjakan versi API yang ada dan mengembangkan yang baru. Dan beberapa versi API telah dikuburkan.
Artikel ini akan berisi banyak hal: bagaimana API dibuat, mengapa layanan cloud membutuhkannya, apa yang diberikannya kepada pengguna, kesalahan apa yang berhasil kami atasi dan apa yang ingin kami lakukan selanjutnya.
Nama saya Oleg Alekseev , Saya adalah direktur teknis dan salah satu pendiri MySklad.
Mengapa membuat API untuk suatu layanan
Klien kami, yaitu puluhan ribu pengusaha, secara aktif menggunakan solusi cloud: perbankan, toko online, akuntansi komoditas, CRM. Setelah Anda terhubung ke salah satunya, sulit untuk menghentikannya. Dan kini layanan kelima, kedelapan, kesepuluh membuat pekerjaan pengusaha lebih mudah, namun pengguna mentransfer data antar layanan cloud tersebut secara manual. Pekerjaan berubah menjadi mimpi buruk.
Solusi yang jelas adalah memberi pengguna kemampuan untuk mentransfer data antar layanan cloud. Misalnya mengimpor dan mengekspor data sebagai file, yang kemudian dapat diunggah ke layanan yang diinginkan. File biasanya diubah agar sesuai dengan format masing-masing layanan. Ini merupakan pekerjaan manual yang kurang lebih sederhana, namun seiring bertambahnya jumlah layanan ini, pelaksanaannya menjadi semakin sulit.
Oleh karena itu, langkah selanjutnya adalah API. Dengan itu, layanan cloud mendapat manfaat dari fakta bahwa ia menghubungkan beberapa layanan pada satu titik. Munculnya ekosistem seperti itu menarik pelanggan baru karena adanya peluang tambahan. Produk dengan fungsionalitas baru menjadi lebih menguntungkan dan bermanfaat.
Jika Anda membuat antarmuka pemrograman sendiri, ini akan menarik tenaga penjualan pihak ketiga dalam bentuk pemrogram yang mengetahui produk Anda berkat API. Mereka mulai membangun solusi berdasarkan API yang diusulkan dan menghasilkan uang dengan mengotomatiskan tugas-tugas pelanggan mereka.
Sistem akuntansi MySklad didasarkan pada proses sederhana. Yang utama adalah bekerja dengan dokumen utama, kemampuan menerima dan mengirimkan barang, serta menerima laporan bisnis berdasarkan dokumen utama. Ada juga transfer data, misalnya ke cloud akuntansi, dan penerimaannya dari sistem perbankan atau gerai ritel. Kami juga bekerja sama dengan toko online: kami menerima informasi tentang produk dan mengirimkan informasi tentang saldo.
API pertama MySklad
Selama 10 tahun MySklad bekerja dengan API, kami telah memperoleh segala macam integrasi yang memungkinkan kami bertukar data, bekerja dengan bank, melakukan pembayaran, dan menggunakan telepon eksternal.
Pada tahun pertama, kami memungkinkan pengunduhan data apa pun dalam format XML. Saat itu, lebih jelas dan umum bagi pengguna untuk menyimpan data secara offline, dan bukan di cloud, dan kami memberikannya kepada mereka. Pengunggahan dimulai dengan ekspor manual dari antarmuka. Artinya, belum bisa disebut API.
Pada saat yang sama, kami mulai bekerja sama dengan perusahaan Rusagro - mereka sudah menggunakan ERP "dewasa" untuk perencanaan produksi dan penjualan, tetapi mereka mengotomatiskan pemuatan mobil di pabrik di MySklad. Beginilah cara kami mendapatkan dasar pertama API yang sebenarnya: pertukaran antara layanan kami dan ERP terjadi dengan mengirimkan file besar berisi data pada semua jenis dokumen.
Ini adalah pilihan yang baik untuk pertukaran data batch, namun bersama dengan dokumen kami harus mentransfer ketergantungannya: informasi tentang barang, kontraktor, dan gudang. Dump seperti itu tidak begitu sulit untuk dihasilkan saat mengekspor, tetapi cukup sulit untuk diuraikan saat mengimpor, karena semua informasi hadir dalam satu paket: baik tentang dokumen baru maupun yang sudah ada.
XML API pertama tidak bertahan lama - dua tahun kemudian kami mulai membangunnya kembali. Bahkan pada awal pengerjaannya, kami membuat beberapa kesalahan saat membangun antarmuka perangkat lunak.
Bagaimana XML API dibuat: ilustrasi dari salah satu arsitek kami. Ngomong-ngomong, nantikan terus artikelnya.
Inilah kesalahan utama kami:
- Markup JAXB dilakukan langsung pada kacang entitas. Kami menggunakan Hibernate untuk berkomunikasi dengan database, dan markup JAXB dibuat untuk kacang yang sama. Kesalahan ini segera muncul: setiap pembaruan pada struktur data menyebabkan kebutuhan untuk segera memberi tahu semua orang yang menggunakan API, atau untuk membuat kruk yang akan memastikan kompatibilitas dengan struktur data sebelumnya.
- API berkembang sebagai add-on, dan pada awalnya kami tidak menentukan bagian mana dari produk tersebut. Mereka bahkan tidak memikirkan apakah API itu penting, apakah perlu menjaga kompatibilitas ke belakang untuk klien pertamanya. Pada suatu saat, jumlah pengguna API hanya sekitar 5% dari jumlah yang kecil, dan tidak ada perhatian yang diberikan kepada mereka. Pemfilteran universal yang dilakukan pada satu waktu menyebabkan kami digunakan sebagai backend. Pemfilteran ini sama sekali bukan GraphQL, tetapi sesuatu seperti itu - pemfilteran ini berfungsi melalui banyak parameter string kueri. Dengan alat canggih seperti itu, sulit bagi pengguna untuk menolaknya, dan permintaan ditransfer kepada kami sehingga dikirim langsung dari UI toko online mereka. Situasi ini merupakan kejutan yang tidak menyenangkan, karena penyediaan layanan semacam itu memerlukan harga yang berbeda dan pemahaman yang berbeda secara umum tentang API itu sendiri sebagai sebuah produk.
- Karena API tidak dikembangkan sebagai produk utama, dokumentasi API diproduksi dan dipublikasikan secara sisa - melalui rekayasa balik. Jalur ini tampaknya cukup sederhana dan nyaman, tetapi bertentangan dengan bekerja berdasarkan kontrak. Ini adalah ketika ada komponen tertentu dengan skema operasi yang telah ditentukan sebelumnya. Pengembang mengimplementasikannya sesuai dengan skema dan tugas ini, komponen diuji, dan klien menerima produk yang sesuai dengan ide analis. Rekayasa balik melemparkan ke pasar produk yang sudah ada: dengan kruk, solusi aneh, dan sepeda alih-alih fungsi yang diperlukan.
- Seluruh aliran permintaan yang datang melalui API dapat dianalisis tidak lebih dari log Nginx atau server aplikasi. Hal ini tidak memungkinkan kami mengidentifikasi bidang subjek, kecuali mungkin berdasarkan pengguna dan pelanggan. Jika tidak ada cara untuk mengatur pendaftaran aplikasi atau klien, analisis situasinya menjadi tidak mungkin. Masalah ini memiliki dampak paling kecil terhadap pengembangan API; ini lebih pada pemahaman relevansi dan fungsionalitasnya.
Percobaan nomor dua: REST API
Pada tahun 2010, kami mencoba membangun sistem pertukaran dengan akuntansi online - BukhSoft. Tidak lepas landas. Namun selama proses integrasi, API lengkap muncul: layanan pertukaran REST, di mana tidak ada kebebasan seperti mengakses operasi dalam bentuk panggilan RPC. Semua komunikasi dengan API dibawa ke mode istirahat standar: baris kueri berisi nama entitas, dan operasi yang dilakukan dengannya ditentukan menggunakan metode http. Kami menambahkan pemfilteran berdasarkan kapan entitas diperbarui, dan pengguna kini memiliki kesempatan untuk membangun replikasi dengan sistem mereka.
Pada tahun yang sama, API untuk membongkar saldo gudang dan inventaris muncul. Bagian paling berharga dari sistem telah tersedia bagi pengguna melalui API - pertukaran dokumen utama dan data perhitungan tentang saldo dan harga pokok barang.
Pada bulan Desember 2015, RetailCRM menerbitkan perpustakaan pihak ketiga pertama yang mengakses API kami. Ini mulai digunakan dengan cukup aktif, sementara popularitas layanan secara keseluruhan meningkat, beban pada API tumbuh lebih cepat daripada beban pada antarmuka web. Pertumbuhan suatu hari berubah menjadi lonjakan beban.
Dan lompatan ini, yang ditunjukkan oleh panah di sebelah kiri, benar-benar membuat takjub server yang melayani API kami. Kami menghabiskan waktu seminggu untuk mencari tahu apa sebenarnya yang menyebabkan beban ini. Ternyata ini adalah permintaan yang sama yang dikirimkan ke API kami dari sisi klien. Sekitar 50 pelanggan memakan semuanya. Saat itulah kami menyadari salah satu kesalahan kami - kurangnya batasan.
Oleh karena itu, kami memberlakukan batasan jumlah permintaan secara bersamaan. Sekarang dimungkinkan untuk membuka tidak lebih dari dua permintaan secara bersamaan dari satu akun. Ini cukup untuk bekerja dalam mode replikasi untuk pertukaran data dalam mode batch. Dan mereka yang ingin menggunakan kami sebagai backend, sejak saat itu, terpaksa harus lebih mematuhi tarif, karena mereka memasukkan pekerjaan pada beberapa akun ke dalam perangkat lunak mereka.
Mari kita bereskan
Sejak tahun 2014, permintaan terhadap API yang ada telah menjadi bagian penting dari bisnis, dan API itu sendiri menghasilkan volume data terbesar dalam pertukaran data dengan klien. Pada tahun 2015, kami meluncurkan proyek untuk membersihkan API. Kami memilih JSON daripada XML sebagai formatnya dan mulai membangunnya berdasarkan fitur yang diidentifikasi selama implementasi versi sebelumnya:
- Kemampuan untuk mengelola versi. Pembuatan versi memungkinkan Anda mengembangkan versi baru tanpa memengaruhi aplikasi yang sudah ada atau mengganggu pengalaman pengguna.
- Kemampuan pengguna untuk melihat metadata dalam respons yang diterimanya.
- Kemampuan untuk bertukar dokumen berukuran besar. Jika kita memproses dokumen dengan lebih dari 4-5 ribu posisi, ini menjadi masalah bagi server: transaksi panjang, permintaan http panjang. Kami membangun mekanisme khusus yang memungkinkan Anda memperbarui dokumen sebagian dan mengelola posisi individual dokumen ini dengan mengirimkannya ke server.
- Alat untuk replikasi juga hadir di versi sebelumnya.
- Batasan muatan ibarat warisan penggaruk yang diinjak di versi sebelumnya. Kami memperkenalkan batasan jumlah permintaan dalam jangka waktu tertentu, jumlah permintaan paralel, dan permintaan dari satu alamat IP.
Sejak itu, kami telah merilis dua versi kecil API dan meluncurkan beberapa API khusus, namun pendekatan keseluruhannya tetap tidak berubah. Format pertukaran yang diperbarui dan arsitektur baru memungkinkan perbaikan kekurangan pada API lebih cepat.
API MySklad hari ini
Saat ini, MySklad API memecahkan banyak masalah:
- pertukaran data dengan toko online, sistem akuntansi, bank;
- memperoleh data dan laporan yang diperhitungkan;
- gunakan sebagai backend untuk aplikasi klien - aplikasi seluler dan mesin kasir desktop kami berfungsi melalui API
- mengirimkan pemberitahuan tentang perubahan data di MySklad - webhook;
- telepon;
- sistem loyalitas.
Berdasarkan API, CEO kami Askar Rakhimberdiev dalam empat jam saya menulis bot telegram yang menarik sisa makanan melalui API:
Sekarang angka-angka kering.
Berikut statistik kami untuk REST API lama:
- 400 perusahaan;
- 600 pengguna;
- 2 juta permintaan per hari;
- 200 GB/hari lalu lintas keluar.
Dan inilah yang kami hasilkan untuk semua API MySklad:
- lebih dari 70 integrasi (beberapa di antaranya dapat dilihat di sini );
- 8500 perusahaan;
- 12 pengguna;
- 46 juta permintaan per hari;
- 2 TB/hari lalu lintas keluar.
Apa Selanjutnya
Rencana pengembangan API sedang dalam diskusi aktif. Kami mencoba mempertimbangkan pengalaman pengoperasian yang diberikan pengguna kepada kami. Tidak selalu mungkin untuk melakukan semuanya sekaligus, namun versi baru API akan segera hadir dengan metadata yang lebih nyaman dan struktur yang tidak terlalu rumit, OAuth untuk autentikasi, dan API untuk aplikasi yang dibangun ke dalam antarmuka.
Anda dapat mengikuti berita di situs web khusus untuk pengembang integrasi dengan MySklad: .
Sumber: www.habr.com