La primera API de MySklad va aparèixer fa 10 anys. Durant tot aquest temps hem estat treballant en versions existents de l'API i desenvolupant-ne de noves. I ja s'han enterrat diverses versions de l'API.
Aquest article inclourà moltes coses: com es va crear l'API, per què el necessita el servei al núvol, què ofereix als usuaris, quins errors hem aconseguit trepitjar i què volem fer després.
Em dic Oleg Alekseev , sóc el director tècnic i cofundador de MySklad.
Per què fer una API per a un servei
Els nostres clients, que són desenes de milers d'emprenedors, utilitzen activament solucions al núvol: banca, botigues en línia, comptabilitat de mercaderies, CRM. Un cop connectat a un, és difícil aturar-se. I ara el cinquè, vuitè, desè servei facilita la feina de l'empresari, però els usuaris transfereixen les dades entre aquests serveis al núvol manualment. La feina es converteix en un malson.
La solució òbvia és donar als usuaris la possibilitat de transferir dades entre serveis al núvol. Per exemple, importeu i exporteu dades com a fitxers, que després es poden carregar al servei desitjat. Normalment, els fitxers es canvien per adaptar-se al format de cada servei. Es tracta d'un treball manual més o menys senzill, però amb l'augment del nombre d'aquests serveis, cada cop es fa més difícil de realitzar.
Per tant, el següent pas és l'API. Amb ell, el servei al núvol es beneficia del fet que connecta diversos serveis en un moment. L'aparició d'aquest ecosistema atrau nous clients a causa d'oportunitats addicionals. Un producte amb noves funcionalitats es fa més rendible i útil.
Si creeu les vostres pròpies interfícies de programació, això atrau vendes de tercers en forma de programadors que coneixen el vostre producte gràcies a l'API. Comencen a construir solucions basades en l'API proposada i guanyen diners automatitzant les tasques dels seus clients.
El sistema de comptabilitat MySklad es basa en processos senzills. El més important és treballar amb documents primaris, la capacitat d'acceptar i enviar mercaderies i rebre informes comercials basats en documents primaris. També hi ha la transferència de dades, per exemple a la comptabilitat en núvol, i la seva recepció de sistemes bancaris o punts de venda. També treballem amb botigues en línia: rebem informació sobre productes i enviem informació sobre saldos.
La primera API de MySklad
Durant els 10 anys que MySklad treballa amb API, hem adquirit tot tipus d'integracions que ens permeten intercanviar dades, treballar amb bancs, fer pagaments i utilitzar la telefonia externa.
El primer any vam fer possible descarregar qualsevol dada en format XML. Aleshores, era molt més clar i més habitual que els usuaris mantinguessin les dades fora de línia, i no en algun núvol, i els hi vam donar. La càrrega es va iniciar mitjançant una exportació manual des de la interfície. És a dir, encara no es podria anomenar API.
Al mateix temps, vam començar a cooperar amb l'empresa Rusagro: ja feien servir un ERP "adult" per a la planificació de la producció i les vendes, però van automatitzar la càrrega de cotxes a les fàbriques de MySklad. Així és com vam aconseguir els primers rudiments d'una API real: l'intercanvi entre el nostre servei i l'ERP es va fer mitjançant l'enviament d'un fitxer gran amb dades de tot tipus de documents.
Aquesta és una bona opció per a l'intercanvi de dades per lots, però juntament amb els documents hem hagut de transferir les seves dependències: informació sobre mercaderies, contractistes i magatzems. Aquest abocador no és tan difícil de generar en exportar, però és bastant difícil d'analitzar quan s'importa, ja que tota la informació ve en un sol paquet: tant sobre documents nous com sobre documents existents.
La primera API XML no va viure gaire: dos anys més tard vam començar a reconstruir-la. Fins i tot al començament del seu treball, vam cometre diversos errors en crear la interfície del programari.
Com es va fer l'API XML: il·lustració d'un dels nostres arquitectes. Per cert, estigueu atents als seus articles.
Aquests són els nostres principals errors:
- El marcatge JAXB es va fer directament als beans d'entitat. Utilitzem Hibernate per comunicar-nos amb la base de dades i el marcatge JAXB es va fer per als mateixos beans. Aquest error va aparèixer gairebé immediatament: qualsevol actualització de l'estructura de dades va comportar la necessitat d'avisar urgentment a tothom que utilitza l'API, o de construir crosses que garanteixin la compatibilitat amb l'estructura de dades anterior.
- L'API va créixer com a complement i inicialment no vam definir quina part del producte era. Ni tan sols van pensar en si l'API era alguna cosa important, si era necessari mantenir la compatibilitat enrere per als seus primers clients. En un moment donat, el nombre d'usuaris d'API era al voltant del 5% del nombre reduït i no se'ls va prestar cap atenció. El filtratge universal fet en un moment va fer que ens utilitzem com a backend. Aquest filtratge no era en absolut GraphQL, però alguna cosa així: funcionava amb molts paràmetres de cadena de consulta. Amb una eina tan potent, als usuaris era difícil resistir-se, i les sol·licituds se'ns transferien perquè s'enviïn directament des de la interfície d'usuari de les seves botigues en línia. La situació va ser una sorpresa desagradable, perquè la prestació d'aquest servei hauria de requerir uns preus diferents i una comprensió generalment diferent de la pròpia API com a producte.
- A causa del fet que l'API no es va desenvolupar com a producte principal, la documentació de l'API es va produir i publicar de manera residual, mitjançant enginyeria inversa. Aquest camí sembla bastant senzill i còmode, però contradiu treballar sota un contracte. Això és quan hi ha un component determinat amb un esquema operatiu preestablert. El desenvolupador l'implementa d'acord amb aquest esquema i tasca, el component es prova i el client rep un producte que coincideix amb la idea de l'analista. L'enginyeria inversa llança al mercat un producte que simplement existeix: amb crosses, solucions estranyes i bicicletes en comptes de la funcionalitat necessària.
- Tot el flux de sol·licituds que va arribar a través de l'API es podria analitzar com a res més que un registre del servidor d'aplicacions o Nginx. Això no ens va permetre identificar àrees temàtiques, excepte potser per usuaris i subscriptors. Si no hi ha manera de regular la sol·licitud o el registre de clients, es fa impossible analitzar la situació. Aquest problema va tenir el menor impacte en el desenvolupament de l'API; es tracta més d'entendre la seva rellevància i funcionalitat.
Intent número dos: API REST
L'any 2010, vam intentar construir un sistema d'intercanvi amb comptabilitat en línia: BukhSoft. No es va enlairar. Però durant el procés d'integració, va aparèixer una API completa: un servei d'intercanvi REST, on no hi havia llibertats com accedir a operacions en forma de trucades RPC. Tota la comunicació amb l'API es va portar al mode estàndard per restar: la línia de consulta conté el nom de l'entitat i l'operació que es realitza amb ella s'especifica mitjançant el mètode http. Hem afegit un filtratge basat en quan es van actualitzar les entitats, i els usuaris ara tenen l'oportunitat de crear replicacions amb els seus sistemes.
El mateix any va aparèixer una API per a la descàrrega de balanços de magatzem i inventari. Les parts més valuoses del sistema s'han posat a disposició dels usuaris mitjançant l'API: l'intercanvi de documents primaris i dades calculades sobre els saldos i el cost de les mercaderies.
El desembre de 2015, RetailCRM va publicar la primera biblioteca de tercers per accedir a la nostra API. Va començar a utilitzar-se de manera força activa, mentre que la popularitat del servei en conjunt va créixer, la càrrega de l'API va créixer més ràpidament que la càrrega de la interfície web. Un dia de creixement es va convertir en un augment de càrrega.
I aquest salt, indicat per la fletxa de l'esquerra, va sorprendre completament el servidor que serveix la nostra API. Vam passar una setmana esbrinant què era exactament el que generava aquesta càrrega. Va resultar que aquestes són les mateixes peticions transmeses a la nostra API des dels fronts dels clients. Uns 50 clients es van menjar de tot. Va ser aleshores quan ens vam adonar d'un dels nostres errors: la manca total de límits.
Com a resultat, vam introduir un límit en el nombre de sol·licituds simultànies. Ara és possible obrir no més de dues sol·licituds simultàniament des d'un mateix compte. Això és suficient per treballar en mode de replicació per a l'intercanvi de dades en mode per lots. I els que volien fer-nos servir com a backend, a partir d'aquell moment, es van veure obligats a complir millor les tarifes, ja que van introduir treball en diversos comptes al seu programari.
Posem-ho en ordre
Ja des del 2014, la demanda de l'API existent s'ha convertit en una part important del negoci, i la mateixa API genera el major volum de dades en l'intercanvi de dades amb els clients. El 2015, vam llançar un projecte per netejar l'API. Vam triar JSON en comptes de XML com a format i vam començar a construir-lo a partir de les característiques que es van identificar durant la implementació de la versió anterior:
- Capacitat de gestionar versions. El control de versions us permet desenvolupar una versió nova sense afectar l'aplicació existent ni interrompre l'experiència de l'usuari.
- La capacitat per a l'usuari de veure metadades a la resposta que rep.
- Capacitat per intercanviar documents grans. Si processem un document amb més de 4-5 mil posicions, això es converteix en un problema per al servidor: una transacció llarga, una sol·licitud http llarga. Hem creat un mecanisme especial que permet actualitzar un document per parts i gestionar les posicions individuals d'aquest document enviant-los al servidor.
- Les eines per a la replicació també estaven presents a la versió anterior.
- Els límits de càrrega són com un llegat del rastell que es va trepitjar a la versió anterior. Hem introduït límits en el nombre de sol·licituds en un període de temps, el nombre de sol·licituds paral·leles i les sol·licituds d'una adreça IP.
Des de llavors, hem llançat dues versions menors de l'API i hem llançat diverses API especialitzades, però l'enfocament general no ha canviat. El format d'intercanvi actualitzat i la nova arquitectura van permetre corregir els errors de l'API molt més ràpidament.
MySklad API avui
Avui, l'API MySklad resol molts problemes:
- intercanvi de dades amb botigues en línia, sistemes comptables, bancs;
- obtenció de dades i informes calculats;
- utilitzar com a backend per a aplicacions de client: les nostres aplicacions mòbils i la caixa registradora d'escriptori funcionen mitjançant API
- enviament de notificacions sobre canvis de dades a MySklad - webhooks;
- telefonia;
- sistemes de fidelització.
Basat en l'API, el nostre CEO Askar Rakhimberdiev en quatre hores vaig escriure un bot de telegrama que treu les restes a través de l'API:
Ara números secs.
Aquestes són les nostres estadístiques de l'antiga API REST:
- 400 empreses;
- 600 usuaris;
- 2 milions de sol·licituds per dia;
- 200 GB/dia de trànsit de sortida.
I això és el que hem creat per a totes les API de MySklad:
- més de 70 integracions (algunes d'elles es poden veure aquí );
- 8500 empreses;
- 12 usuaris;
- 46 milions de sol·licituds per dia;
- 2 TB/dia de trànsit de sortida.
Què és el següent
Els plans de desenvolupament de l'API estan en discussió activa. Intentem tenir en compte l'experiència operativa que ens proporcionen els usuaris. No sempre és possible fer-ho tot alhora, però una nova versió de l'API està a la volta de la cantonada amb metadades més còmodes i una estructura menys esponjosa, OAuth per a l'autenticació i una API per a aplicacions integrades a la interfície.
Podeu seguir les notícies en un lloc web especial per a desenvolupadors d'integracions amb MySklad: .
Font: www.habr.com