MySklad API pisanan muncul 10 taun kepungkur. Kabeh wektu iki kita wis nggarap versi API sing wis ana lan ngembangake sing anyar. Lan sawetara versi API wis dikubur.
Artikel iki bakal ngemot akeh perkara: kepiye API digawe, kenapa layanan awan mbutuhake, apa sing diwenehake kanggo pangguna, kesalahan apa sing bisa ditindakake lan apa sing arep ditindakake sabanjure.
Jenengku Oleg Alekseev , Aku direktur technical lan co-pendiri MySklad.
Apa nggawe API kanggo layanan
Klien kita, sing puluhan ewu pengusaha, aktif nggunakake solusi awan: perbankan, toko online, akuntansi komoditas, CRM. Sawise sampeyan nyambung menyang siji, iku angel kanggo mungkasi. Lan saiki layanan kaping lima, kaping wolu, sepuluh nggawe karya pengusaha luwih gampang, nanging pangguna ngirim data ing antarane layanan awan kasebut kanthi manual. Kerja dadi ngipi elek.
Solusi sing jelas yaiku menehi pangguna kemampuan kanggo mindhah data ing antarane layanan awan. Contone, ngimpor lan ngekspor data minangka file, sing banjur bisa diunggah menyang layanan sing dikarepake. File biasane diganti supaya cocog karo format saben layanan. Iki minangka karya manual sing luwih gampang, nanging kanthi nambah jumlah layanan kasebut, dadi luwih angel ditindakake.
Mulane, langkah sabanjure yaiku API. Kanthi, layanan maya entuk manfaat saka kasunyatan sing nyambungake sawetara layanan ing sawijining titik. Muncule ekosistem kasebut narik pelanggan anyar amarga ana kesempatan tambahan. Produk kanthi fungsi anyar dadi luwih nguntungake lan migunani.
Yen sampeyan nggawe antarmuka program dhewe, iki narik kawigaten wong dodolan pihak katelu ing wangun programer sing ngerti babagan produk sampeyan thanks kanggo API. Dheweke wiwit mbangun solusi adhedhasar API sing diusulake lan entuk dhuwit kanthi ngotomatisasi tugas para pelanggan.
Sistem akuntansi MySklad adhedhasar proses sing prasaja. Ingkang utama yaiku nggarap dokumen utami, kemampuan kanggo nampa lan ngirim barang, lan nampa laporan bisnis adhedhasar dokumen utami. Ana uga transfer data, contone menyang akuntansi awan, lan panrimo saka sistem perbankan utawa toko eceran. Kita uga nggarap toko online: kita nampa informasi babagan produk lan ngirim informasi babagan imbangan.
API pisanan MySklad
Swara 10 taun MySklad nggarap API, kita wis entuk kabeh jinis integrasi sing ngidini kita ngganti data, nggarap bank, nggawe pembayaran lan nggunakake telpon eksternal.
Ing taun pisanan, kita bisa ngundhuh data apa wae ing format XML. Mbalik maneh, iku luwih cetha lan luwih umum kanggo pangguna supaya data offline, lan ora ing sawetara maya, lan kita marang wong-wong mau. Unggahan diwiwiti kanthi ekspor manual saka antarmuka. Tegese, durung bisa diarani API.
Ing wektu sing padha, kita wiwit kerja sama karo perusahaan Rusagro - dheweke wis nggunakake ERP "diwasa" kanggo perencanaan produksi lan penjualan, nanging kanthi otomatis ngemot mobil ing pabrik ing MySklad. Iki carane entuk dhasar pisanan saka API nyata: ijol-ijolan antarane layanan lan ERP ditindakake kanthi ngirim file gedhe kanthi data ing kabeh jinis dokumen.
Iki minangka pilihan sing apik kanggo ijol-ijolan data batch, nanging bebarengan karo dokumen, kita kudu nransfer dependensi: informasi babagan barang, kontraktor lan gudang. Dump kuwi ora dadi angel kanggo ngasilake nalika ngekspor, nanging cukup angel kanggo ngurai nalika ngimpor, amarga kabeh informasi kasebut ana ing siji paket: babagan dokumen anyar lan babagan sing wis ana.
XML API pisanan ora urip suwe - rong taun sabanjure kita wiwit mbangun maneh. Malah ing wiwitan karya, kita nggawe sawetara kesalahan nalika mbangun antarmuka piranti lunak.
Kepiye carane XML API digawe: ilustrasi saka salah sawijining arsitek. Ngomong-ngomong, pantengin terus artikel-artikelnya.
Mangkene kesalahan utama kita:
- Markup JAXB ditindakake langsung ing kacang entitas. Kita nggunakake Hibernate kanggo komunikasi karo database, lan JAXB markup digawe kanggo kacang buncis padha. Kesalahan iki katon meh langsung: apa wae nganyari struktur data nyebabake kudu menehi kabar kanthi cepet marang saben wong sing nggunakake API, utawa nggawe kruk sing bakal njamin kompatibilitas karo struktur data sadurunge.
- API tansaya tambah minangka tambahan, lan kita ora nemtokake apa bagean saka produk kasebut. Dheweke ora mikir apa API iku penting, apa perlu kanggo njaga kompatibilitas mundur kanggo klien pisanan. Ing sawijining wektu, jumlah pangguna API kira-kira 5% saka jumlah cilik, lan ora ana perhatian sing dibayar. Nyaring universal sing ditindakake ing siji wektu nyebabake kita digunakake minangka backend. Penyaringan iki dudu GraphQL, nanging kaya ngono - bisa digunakake ing pirang-pirang parameter string pitakon. Kanthi alat sing kuat, pangguna angel nolak, lan panjaluk ditransfer menyang kita supaya dikirim langsung saka UI toko online. Kahanan kasebut minangka kejutan sing ora nyenengake, amarga panyedhiya layanan kasebut kudu mbutuhake rega sing beda lan pangerten sing umume beda babagan API dhewe minangka produk.
- Amarga kasunyatane yen API ora dikembangake minangka produk utama, dokumentasi API diprodhuksi lan diterbitake kanthi basis residual - liwat rekayasa terbalik. Path iki misale jek cukup prasaja lan trep, nanging contradicts digunakake ing kontrak. Iki nalika ana komponen tartamtu kanthi skema operasi prasetel. Pangembang ngetrapake sesuai karo skema lan tugas iki, komponen kasebut diuji, lan klien nampa produk sing cocog karo ide analis. Teknik mbalikke mbuwang menyang pasar produk sing mung ana: kanthi kruk, solusi aneh lan sepeda tinimbang fungsi sing dibutuhake.
- Kabeh aliran panjaluk sing teka liwat API bisa dianalisis minangka ora luwih saka Nginx utawa log server aplikasi. Iki ora ngidini kita ngenali wilayah subyek, kajaba bisa uga pangguna lan pelanggan. Yen ora ana cara kanggo ngatur registrasi aplikasi utawa klien, mula ora bisa nganalisa kahanan kasebut. Masalah iki duweni pengaruh paling sithik ing pangembangan API; luwih akeh babagan ngerteni relevansi lan fungsine.
Nyoba nomer loro: REST API
Ing 2010, kita nyoba mbangun sistem ijol-ijolan karo akuntansi online - BukhSoft. Durung take off. Nanging sajrone proses integrasi, API lengkap katon: layanan ijol-ijolan REST, sing ora ana kebebasan kayata ngakses operasi ing wangun telpon RPC. Kabeh komunikasi karo API digawa menyang mode standar kanggo ngaso: baris query ngemot jeneng entitas, lan operasi sing dileksanakake karo iku ditemtokake nggunakake cara http. Kita nambahake nyaring adhedhasar nalika entitas dianyari, lan pangguna saiki duwe kesempatan kanggo mbangun replikasi karo sisteme.
Ing taun sing padha, ana API kanggo unloading saldo gudang lan persediaan. Bagean sistem sing paling larang wis kasedhiya kanggo pangguna liwat API - ijol-ijolan dokumen utami lan data sing diitung babagan imbangan lan biaya barang.
Ing Desember 2015, RetailCRM nerbitake perpustakaan pihak katelu pisanan kanggo ngakses API kita. Iku wiwit digunakake cukup aktif, nalika popularitas saka layanan sakabèhé tansaya, mbukak ing API luwih cepet saka mbukak ing antarmuka web. Sawijining dina wutah dadi mundhak beban.
Lan mlumpat iki, dituduhake dening panah ing sisih kiwa, rampung kaget server porsi kita API. Kita ngenteni seminggu kanggo ngerteni apa sing ngasilake beban iki. Ternyata iki minangka panjaluk sing padha sing dikirim menyang API saka ngarep klien. Kira-kira 50 pelanggan mangan kabeh. Nalika iku kita nyadari salah sawijining kesalahan - kekurangan watesan.
Akibaté, kita ngenalaken watesan ing jumlah panjalukan simultaneous. Saiki sampeyan bisa mbukak ora luwih saka rong panjalukan bebarengan saka siji akun. Iki cukup kanggo bisa digunakake ing mode replikasi kanggo ijol-ijolan data ing mode kumpulan. Lan wong-wong sing pengin nggunakake kita minangka backend, wiwit wektu iku, dipeksa luwih tundhuk karo tarif, amarga padha ngenalaken karya ing sawetara akun menyang piranti lunak.
Ayo ditata
Wis wiwit 2014, panjaluk kanggo API sing wis ana wis dadi bagean penting saka bisnis, lan API dhewe ngasilake volume data paling gedhe ing ijol-ijolan data karo klien. Ing 2015, kita ngluncurake proyek kanggo ngresiki API. Kita milih JSON tinimbang XML minangka format lan wiwit mbangun adhedhasar fitur sing diidentifikasi sajrone implementasine versi sadurunge:
- Kemampuan kanggo ngatur versi. Versi ngidini sampeyan ngembangake versi anyar tanpa mengaruhi aplikasi sing wis ana utawa ngganggu pengalaman pangguna.
- Kemampuan pangguna kanggo ndeleng metadata ing respon dhewe sing ditampa.
- Kemampuan kanggo ngganti dokumen gedhe. Yen kita ngolah dokumen kanthi luwih saka 4-5 ewu posisi, iki dadi masalah kanggo server: transaksi sing dawa, panyuwunan http sing dawa. Kita mbangun mekanisme khusus sing ngidini sampeyan nganyari dokumen ing bagean lan ngatur posisi individu saka dokumen iki kanthi ngirim menyang server.
- Piranti kanggo replikasi uga ana ing versi sadurunge.
- Watesan beban kaya warisan rake sing ditandhani ing versi sadurunge. We ngenalaken watesan ing jumlah panjalukan ing wektu, nomer panjalukan podo lan panjalukan saka siji alamat IP.
Wiwit iku, kita wis ngeculake rong versi cilik saka API lan ngluncurake sawetara API khusus, nanging pendekatan sakabèhé tetep ora owah. Format ijol-ijolan sing dianyari lan arsitektur anyar ndadekake bisa mbenerake cacat ing API luwih cepet.
MySklad API dina iki
Dina iki, MySklad API ngatasi akeh masalah:
- ijol-ijolan data karo toko online, sistem akuntansi, bank;
- entuk data lan laporan sing diwilang;
- digunakake minangka backend kanggo aplikasi klien - aplikasi seluler lan mesin kasir desktop bisa digunakake liwat API
- ngirim kabar babagan owah-owahan data ing MySklad - webhooks;
- telephony;
- sistem kasetyan.
Adhedhasar API, CEO kita Askar Rakhimberdiev ing patang jam aku nulis bot telegram sing narik turahan liwat API:
Saiki nomer garing.
Iki statistik kanggo REST API lawas:
- 400 perusahaan;
- 600 pangguna;
- 2 yuta panjalukan saben dina;
- 200 GB / dina lalu lintas metu.
Lan ing ngisor iki sing digawe kanggo kabeh API MySklad:
- luwih saka 70 integrasi (sawetara bisa dideleng ing kene );
- 8500 perusahaan;
- 12 pangguna;
- 46 yuta panjalukan saben dina;
- 2 TB / dina lalu lintas metu.
Apa mbesuk
rencana pembangunan API ana ing diskusi aktif. Kita nyoba kanggo njupuk menyang akun pengalaman operasi sing kedhaftar nyedhiyani kita karo. Iku ora tansah bisa kanggo nindakake kabeh bebarengan, nanging versi anyar saka API mung watara sudhut karo metadata luwih trep lan struktur kurang alus, OAuth kanggo bukti asli, lan API kanggo aplikasi dibangun ing antarmuka.
Sampeyan bisa ngetutake kabar ing situs web khusus kanggo pangembang integrasi karo MySklad: .
Source: www.habr.com
