ProHoster > Blogg > Administrasjon > Wrote an API — tore XML (twice)

Wrote an API — tore XML (twice)

Den fĂžrste API-en til MinLager ble lansert for 10 Ă„r siden. Siden den gang har vi arbeidet med eksisterende versjoner av API-en og utviklet nye. Noen versjoner av API-en har allerede blitt lagt bort.

I denne artikkelen vil det vĂŠre mye innhold: hvordan API-en ble utviklet, hvorfor den er nĂždvendig for en skybasert tjeneste, hva den gir brukerne, hvilke feil vi har gjort, og hva vi Ăžnsker Ă„ gjĂžre videre.

Jeg heter Oleg Alexeev oalexeev, jeg er teknisk direktĂžr og medstifter av MinLager.

Hvorfor lage API for tjenesten

Kundene vÄre, som omfatter titusenvis av entreprenÞrer, bruker aktivt skybaserte lÞsninger: banktjenester, nettbutikker, varebeholdningssystemer, CRM. NÄr du kobler til én, blir det vanskelig Ä stoppe. Og nÄ har den femte, Ättende, tiende tjenesten gjort entreprenÞrens arbeid lettere, men dataene mellom disse skybaserte tjenestene mÄ brukerne fremdeles overfÞre manuelt. Arbeidet blir et mareritt.

Det Äpenbare lÞsningen er Ä gi brukerne mulighet til Ä overfÞre data mellom skybaserte tjenester. For eksempel Ä importere og eksportere data som filer som deretter kan lastes opp til den aktuelle tjenesten. Filer tilpasses vanligvis formatet til hver tjeneste. Dette er mer eller mindre enkel manuell arbeid, men med Þkningen i antall disse tjenestene blir det mer komplisert Ä hÄndtere.

Derfor er neste steg – API. Med det fĂ„r den skybaserte tjenesten fordelene av Ă„ knytte flere tjenester pĂ„ ett sted. Fremveksten av et slikt Ăžkosystem tiltrekker nye kunder takket vĂŠre tilleggsmuligheter. Et produkt med ny funksjonalitet blir mer kostnadseffektivt og nyttig.

Å lage egne programmeringsgrensesnitt tiltrekker eksterne selgere i form av programmerere som kjenner produktet ditt takket vĂŠre API. De begynner Ă„ bygge lĂžsninger basert pĂ„ det foreslĂ„tte API og tjener penger pĂ„ Ă„ automatisere oppgaver for kundene sine.

BokfÞringssystemet til MinLager er bygget pÄ enkle prosesser. Hovedsakelig dreier det seg om Ä hÄndtere primÊr dokumentasjon, muligheten til Ä gjennomfÞre mottak og utsendelse av varer, og Ä generere rapporter for bedriften basert pÄ primÊrdata. Det er ogsÄ dataoverfÞring, for eksempel til skybasert regnskap, samt mottak av data fra banksystemer eller detaljutsalg. I tillegg arbeider vi med nettbutikker: vi fÄr informasjon om produkter og sender data om beholdningen.

Wrote an API — tore XML (twice)

FĂžrste API til MinLager

I lĂžpet av de 10 Ă„rene MinLager har jobbet med API, har vi samlet mange integrasjoner som gjĂžr det mulig Ă„ utveksle data, arbeide med banker, gjennomfĂžre betalinger og bruke ekstern telefoni.

I det fĂžrste Ă„ret lagde vi muligheten til Ă„ eksporterer alle data i XML-format. Den gangen var det mye mer vanlig og kjent for brukerne Ă„ holde dataene offline, snarere enn i noen sky, og vi ga dem det. Eksportprosessen ble initiert via manuell eksport fra grensesnittet. Det var dermed ikke noe man kunne kalle et API.

Samtidig begynte vi samarbeidet med selskapet Rusagro – de brukte allerede et 'modent' ERP-system for produksjons- og distribusjonsplanlegging, men automatiseringen av lasting av vognene pĂ„ fabrikkene ble gjort i MinLager. SĂ„ fikk vi vĂ„re fĂžrste frĂž til et ekte API: utvekslingen mellom tjenesten vĂ„r og ERP-systemet skjedde ved Ă„ sende en stor fil med data for alle dokumenttyper.

Dette var en grei lĂžsning for batch-utveksling av data, men sammen med dokumentene mĂ„tte man ogsĂ„ sende avhengighetene deres: informasjon om varer, kontraktsparter og lagre. Å generere en slik blanding er ikke sĂ„ vanskelig ved eksport, men det er ganske vanskelig Ă„ sortere den ved import, ettersom all informasjon kommer i Ă©n pakke: bĂ„de om nye dokumenter og om eksisterende.

Det fĂžrste XML APIet levde ikke lenge – etter to Ă„r begynte vi Ă„ omstrukturere det. Allerede tidlig i driftsfasen gjorde vi flere feil i oppbyggingen av grensesnittet.

Wrote an API — tore XML (twice)
Slik ble XML API laget: illustrasjonen er laget av en av vÄre arkitekter. Forresten, se frem til hans artikler.

Her er vÄre hovedfeil:

  1. JAXB-merking ble gjort direkte pÄ entity beans. For kommunikasjon med databasen bruker vi Hibernate, og JAXB-merking ble gjort pÄ de samme bÞnnene. Denne feilen dukket opp nesten umiddelbart: hver oppdatering av datakonstruksjonen fÞrte til at alle som brukte API mÄtte varsles omgÄende, eller man mÄtte lage 'klosser' som sikret kompatibilitet med den tidligere datakonstruksjonen.
  2. API utviklet seg som et supplement, og i starten definerte vi ikke hvilken del av produktet det utgjorde. Vi tenkte ikke over om API var viktig, eller om vi mĂ„tte opprettholde bakoverkompatibilitet for de fĂžrste kundene. PĂ„ et tidspunkt utgjorde antallet API-brukere omtrent 5% av det totale lille antallet, og vi ga dem ikke noe oppmerksomhet. Den universelle filtreringen som ble gjort tidligere fĂžrte til at vi ble brukt som backend. Denne filtreringen var ikke helt GraphQL, men noe lignende — det fungerte gjennom en mengde parametere i forespĂžrselen. Med et sĂ„ kraftig verktĂžy var det vanskelig for brukerne Ă„ motstĂ„, og forespĂžrslene ble sendt direkte fra UI-en til nettbutikkene deres. Situasjonen ble et ubehagelig overraskelse, fordi Ă„ tilby en slik tjeneste burde kreve en annen prising og en helt annen forstĂ„else av API som produkt.
  3. Fordi API utviklet seg ikke som et hovedprodukt, ble dokumentasjonen for API produsert og publisert pĂ„ et etterlĂžpende grunnlag — gjennom reversering av ingeniĂžrarbeid. Denne tilnĂŠrmingen virker ganske enkel og praktisk, men er i strid med kontraktsarbeid. Det er nĂ„r det er en komponent med en forhĂ„ndsbestemt arbeidsordning. Utvikleren implementerer den i henhold til denne ordningen og oppgaven, komponenten gjennomgĂ„r testing, og kunden mottar produktet som samsvarer med analytikerenes visjon. Reversering av ingeniĂžrarbeid kaster imidlertid et produkt pĂ„ markedet som bare eksisterer: med lappelĂžsninger, merkelige beslutninger og
  4. Hele strÞmmen av forespÞrselene som kom gjennom API-en kunne ikke analyseres mer enn som en logg fra Nginx eller applikasjonsserveren. Dette tillot ikke Ä fremheve temaomrÄder, bortsett fra Ä dele opp etter brukere og abonnenter. Hvis det ikke er mulighet til Ä regulere registreringen av applikasjonen eller kundene, blir det umulig Ä analysere situasjonen. Dette problemet pÄvirket pÄ en minimal mÄte utviklingen av API-en; det handler mer om forstÄelsen av etterspÞrselen og funksjonaliteten.

ForsĂžk nummer to: REST API

I 2010 prĂžvde vi Ă„ bygge et system for utveksling med online-regnskapet – BukhSoft. Det ble ikke vellykket. Men i prosessen med integrasjonen oppstod det et fullt API: et REST-tjeneste for utveksling, hvor det ikke var rom for unntak som RPC-kall. All kommunikasjon med API-et ble fĂžrt over i den standardiserte REST-modusen: i forespĂžrselen er navnet pĂ„ enheten og operasjonen som utfĂžres, bestemmes ved hjelp av HTTP-metoden. Vi la til filtrering etter oppdateringspunktene for enhetene, og brukerne fikk mulighet til Ă„ bygge replikering med sine egne systemer.

Samme Ă„r ble det laget et API for Ă„ eksportere lager- og varebeholdning. Gjennom API-et ble de mest verdifulle delene av systemet tilgjengelige for brukerne – utveksling av primĂŠr dokumentasjon og beregningsdata for beholdningene og kostnadene av varene.

I desember 2015 publiserte RetailCRM det fÞrste tredjepartsbiblioteket for tilgang til vÄrt API. Det ble ganske aktivt brukt, samtidig som populariteten til tjenesten generelt vokste, og belastningen pÄ API-et Þkte raskere enn belastningen pÄ webgrensesnittet. En gang ble veksten til et sjokk.

Wrote an API — tore XML (twice)

Wrote an API — tore XML (twice)

Og dette sjokket, som pilen til venstre viser, fĂžrte til fullstendig forblĂžffelse av serveren som betjente vĂ„rt API. I en uke jobbet vi med Ă„ finne ut hva som forĂ„rsaket denne belastningen. Det viste seg at det var nettopp de forespĂžrslene som ble sendt til vĂ„rt API fra klientenes fronter. Rundt 50 klienter skapte belastningen. Her innsĂ„ vi en av vĂ„re feil – den totale mangelen pĂ„ grenser.

Som et resultat innfÞrte vi en grense for antall samtidige forespÞrsel. Fra en konto ble det nÄ tillatt Ä Äpne maksimalt to forespÞrsel samtidig. Dette er tilstrekkelig for Ä jobbe i replikasjonsmodus for datautveksling i batchmodus. De som ville bruke oss som backend, mÄtte fra dette punktet mer tilpasse seg prisplanene, ettersom de innfÞrte arbeid med flere kontoer i programvaren sin.

Orden i rekken

Allerede fra 2014 ble etterspÞrselen etter det eksisterende API-et en viktig del av virksomheten, og API-et genererte den stÞrste datamengden i datautveksling med kundene. I 2015 startet vi et prosjekt for Ä rydde opp i API-et. Vi valgte JSON som format i stedet for XML og begynte Ä bygge det pÄ grunnlag av de egenskapene vi avdekket under implementeringen av den forrige versjonen:

  1. Muligheten til Ă„ administrere versjoner. Versjonering gjĂžr det mulig Ă„ utvikle en ny versjon uten Ă„ berĂžre eksisterende applikasjoner og uten Ă„ forstyrre brukerne.
  2. Muligheten for brukeren Ä se metadata i svaret han fÄr.
  3. Muligheten til Ä utveksle store dokumenter. NÄr vi behandler et dokument med flere enn 4-5 tusen poster, blir det et problem for serveren: lange transaksjoner, lange http-forespÞrsel. Vi har bygget en spesialmekanisme som lar oss oppdatere dokumentet del for del og hÄndtere individuelle poster i dette dokumentet ved Ä sende dem til serveren.
  4. VerktĂžy for replikasjon – var ogsĂ„ i forrige versjon.
  5. Belastningsgrenser – som et resultat av problemene vi stĂžtte pĂ„ i forrige versjon. Vi innfĂžrte grenser for antall forespĂžrsel innen en tidsramme, antall parallelle forespĂžrsel og forespĂžrsel fra Ă©n ip-adresse.

Siden da har vi utgitt to mindre versjoner av API-et og lansert flere spesialiserte API-er, men generelt har tilnĂŠrmingen forblitt uendret. Den oppdaterte utvekslingsformatet og den nye arkitekturen har gjort det mulig Ă„ rette opp mangler i API-et mye raskere.

API-en til MinLager i dag

I dag lĂžser API-en til MinLager mange oppgaver:

  • datautveksling med nettbutikker, regnskapssystemer, banker;
  • innhenting av beregningsdata, rapporter;
  • bruk som backend for klientapplikasjoner – vĂ„re mobile applikasjoner og stasjonĂŠre kasser arbeider gjennom API-et.
  • sending av varsler om endringer i dataene i MinLager – webhooks;
  • telefoni;
  • lojalitetssystemer.

Basert pÄ API-et skrev vÄr administrerende direktÞr Askar Rakhimberdiev rhino pÄ fire timer en telegram-bot som henter lagerbeholdningene via API-et: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

NĂ„ tĂžrre tall.

Her er vÄr statistikk for det gamle REST API-et:

  • 400 selskaper;
  • 600 brukere;
  • 2 millioner forespĂžrsel per dag;
  • 200 GB/dag utgĂ„ende trafikk.

Og her er hva vi har oppnÄdd med alle API-ene til MinLager:

  • over 70 integrasjoner (noen av dem kan sees her www.moysklad.ru/integratsii);
  • 8500 selskaper;
  • 12 000 brukere;
  • 46 millioner forespĂžrsel per dag;
  • 2 TB/dag utgĂ„ende trafikk.

Hva nÄ

API-utviklingsplanene er i aktiv diskusjon. Vi prĂžver Ă„ ta hensyn til driftsopplevelsen som brukerne gir oss. Ikke alt kan alltid gjĂžres med en gang, men en ny versjon av API-et med mer brukervennlige metadata og mindre komplisert struktur, OAuth for autentisering, og API for applikasjonsintegrasjoner er like rundt hjĂžrnet.

Du kan fÞlge med pÄ nyhetene pÄ en spesialside for utviklere som integrerer med MinLager: dev.minklager.ru.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster