{"id":34354,"date":"2019-10-31T21:57:51","date_gmt":"2019-10-31T18:57:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pisali-api-porvali-xml-dva\/"},"modified":"2019-10-31T21:57:51","modified_gmt":"2019-10-31T18:57:51","slug":"pisali-api-porvali-xml-dva","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"Wrote an API \u2014 tore XML (twice)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Den f\u00f8rste API-en til MinLager ble lansert for 10 \u00e5r 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. <\/p>\n

I denne artikkelen vil det v\u00e6re mye innhold: hvordan API-en ble utviklet, hvorfor den er n\u00f8dvendig for en skybasert tjeneste, hva den gir brukerne, hvilke feil vi har gjort, og hva vi \u00f8nsker \u00e5 gj\u00f8re videre.
\n<\/a><\/noindex>
\nJeg heter Oleg Alexeev oalexeev<\/a><\/noindex>, jeg er teknisk direkt\u00f8r og medstifter av MinLager. <\/p>\n

Hvorfor lage API for tjenesten<\/h2>\n

\nKundene v\u00e5re, som omfatter titusenvis av entrepren\u00f8rer, bruker aktivt skybaserte l\u00f8sninger: banktjenester, nettbutikker, varebeholdningssystemer, CRM. N\u00e5r du kobler til \u00e9n, blir det vanskelig \u00e5 stoppe. Og n\u00e5 har den femte, \u00e5ttende, tiende tjenesten gjort entrepren\u00f8rens arbeid lettere, men dataene mellom disse skybaserte tjenestene m\u00e5 brukerne fremdeles overf\u00f8re manuelt. Arbeidet blir et mareritt.<\/p>\n

Det \u00e5penbare l\u00f8sningen er \u00e5 gi brukerne mulighet til \u00e5 overf\u00f8re data mellom skybaserte tjenester. For eksempel \u00e5 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 \u00f8kningen i antall disse tjenestene blir det mer komplisert \u00e5 h\u00e5ndtere.<\/p>\n

Derfor er neste steg \u2013 API. Med det f\u00e5r den skybaserte tjenesten fordelene av \u00e5 knytte flere tjenester p\u00e5 ett sted. Fremveksten av et slikt \u00f8kosystem tiltrekker nye kunder takket v\u00e6re tilleggsmuligheter. Et produkt med ny funksjonalitet blir mer kostnadseffektivt og nyttig.<\/p>\n

\u00c5 lage egne programmeringsgrensesnitt tiltrekker eksterne selgere i form av programmerere som kjenner produktet ditt takket v\u00e6re API. De begynner \u00e5 bygge l\u00f8sninger basert p\u00e5 det foresl\u00e5tte API og tjener penger p\u00e5 \u00e5 automatisere oppgaver for kundene sine.<\/p>\n

Bokf\u00f8ringssystemet til MinLager er bygget p\u00e5 enkle prosesser. Hovedsakelig dreier det seg om \u00e5 h\u00e5ndtere prim\u00e6r dokumentasjon, muligheten til \u00e5 gjennomf\u00f8re mottak og utsendelse av varer, og \u00e5 generere rapporter for bedriften basert p\u00e5 prim\u00e6rdata. Det er ogs\u00e5 dataoverf\u00f8ring, for eksempel til skybasert regnskap, samt mottak av data fra banksystemer eller detaljutsalg. I tillegg arbeider vi med nettbutikker: vi f\u00e5r informasjon om produkter og sender data om beholdningen.<\/p>\n

\"Wrote
\n<\/p>\n

F\u00f8rste API til MinLager<\/h2>\n

\nI l\u00f8pet av de 10 \u00e5rene MinLager har jobbet med API, har vi samlet mange integrasjoner som gj\u00f8r det mulig \u00e5 utveksle data, arbeide med banker, gjennomf\u00f8re betalinger og bruke ekstern telefoni.<\/p>\n

I det f\u00f8rste \u00e5ret lagde vi muligheten til \u00e5 eksporterer alle data i XML-format. Den gangen var det mye mer vanlig og kjent for brukerne \u00e5 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. <\/p>\n

Samtidig begynte vi samarbeidet med selskapet Rusagro \u2013 de brukte allerede et 'modent' ERP-system for produksjons- og distribusjonsplanlegging, men automatiseringen av lasting av vognene p\u00e5 fabrikkene ble gjort i MinLager. S\u00e5 fikk vi v\u00e5re f\u00f8rste fr\u00f8 til et ekte API: utvekslingen mellom tjenesten v\u00e5r og ERP-systemet skjedde ved \u00e5 sende en stor fil med data for alle dokumenttyper. <\/p>\n

Dette var en grei l\u00f8sning for batch-utveksling av data, men sammen med dokumentene m\u00e5tte man ogs\u00e5 sende avhengighetene deres: informasjon om varer, kontraktsparter og lagre. \u00c5 generere en slik blanding er ikke s\u00e5 vanskelig ved eksport, men det er ganske vanskelig \u00e5 sortere den ved import, ettersom all informasjon kommer i \u00e9n pakke: b\u00e5de om nye dokumenter og om eksisterende.<\/p>\n

Det f\u00f8rste XML APIet levde ikke lenge \u2013 etter to \u00e5r begynte vi \u00e5 omstrukturere det. Allerede tidlig i driftsfasen gjorde vi flere feil i oppbyggingen av grensesnittet.<\/p>\n

\"Wrote
\nSlik ble XML API laget: illustrasjonen er laget av en av v\u00e5re arkitekter. Forresten, se frem til hans artikler.<\/i><\/p>\n

Her er v\u00e5re hovedfeil:<\/p>\n

    \n
  1. JAXB-merking ble gjort direkte p\u00e5 entity beans. For kommunikasjon med databasen bruker vi Hibernate, og JAXB-merking ble gjort p\u00e5 de samme b\u00f8nnene. Denne feilen dukket opp nesten umiddelbart: hver oppdatering av datakonstruksjonen f\u00f8rte til at alle som brukte API m\u00e5tte varsles omg\u00e5ende, eller man m\u00e5tte lage 'klosser' som sikret kompatibilitet med den tidligere datakonstruksjonen.<\/li>\n
  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\u00e5tte opprettholde bakoverkompatibilitet for de f\u00f8rste kundene. P\u00e5 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\u00f8rte til at vi ble brukt som backend. Denne filtreringen var ikke helt GraphQL, men noe lignende \u2014 det fungerte gjennom en mengde parametere i foresp\u00f8rselen. Med et s\u00e5 kraftig verkt\u00f8y var det vanskelig for brukerne \u00e5 motst\u00e5, og foresp\u00f8rslene ble sendt direkte fra UI-en til nettbutikkene deres. Situasjonen ble et ubehagelig overraskelse, fordi \u00e5 tilby en slik tjeneste burde kreve en annen prising og en helt annen forst\u00e5else av API som produkt.<\/li>\n
  3. Fordi API utviklet seg ikke som et hovedprodukt, ble dokumentasjonen for API produsert og publisert p\u00e5 et etterl\u00f8pende grunnlag \u2014 gjennom reversering av ingeni\u00f8rarbeid. Denne tiln\u00e6rmingen virker ganske enkel og praktisk, men er i strid med kontraktsarbeid. Det er n\u00e5r det er en komponent med en forh\u00e5ndsbestemt arbeidsordning. Utvikleren implementerer den i henhold til denne ordningen og oppgaven, komponenten gjennomg\u00e5r testing, og kunden mottar produktet som samsvarer med analytikerenes visjon. Reversering av ingeni\u00f8rarbeid kaster imidlertid et produkt p\u00e5 markedet som bare eksisterer: med lappel\u00f8sninger, merkelige beslutninger og <\/li>\n
  4. Hele str\u00f8mmen av foresp\u00f8rselene som kom gjennom API-en kunne ikke analyseres mer enn som en logg fra Nginx eller applikasjonsserveren. Dette tillot ikke \u00e5 fremheve temaomr\u00e5der, bortsett fra \u00e5 dele opp etter brukere og abonnenter. Hvis det ikke er mulighet til \u00e5 regulere registreringen av applikasjonen eller kundene, blir det umulig \u00e5 analysere situasjonen. Dette problemet p\u00e5virket p\u00e5 en minimal m\u00e5te utviklingen av API-en; det handler mer om forst\u00e5elsen av ettersp\u00f8rselen og funksjonaliteten.<\/li>\n<\/ol>\n

    <\/p>\n

    Fors\u00f8k nummer to: REST API<\/h2>\n

    \nI 2010 pr\u00f8vde vi \u00e5 bygge et system for utveksling med online-regnskapet \u2013 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\u00f8rt over i den standardiserte REST-modusen: i foresp\u00f8rselen er navnet p\u00e5 enheten og operasjonen som utf\u00f8res, bestemmes ved hjelp av HTTP-metoden. Vi la til filtrering etter oppdateringspunktene for enhetene, og brukerne fikk mulighet til \u00e5 bygge replikering med sine egne systemer.<\/p>\n

    Samme \u00e5r ble det laget et API for \u00e5 eksportere lager- og varebeholdning. Gjennom API-et ble de mest verdifulle delene av systemet tilgjengelige for brukerne \u2013 utveksling av prim\u00e6r dokumentasjon og beregningsdata for beholdningene og kostnadene av varene.<\/p>\n

    I desember 2015 publiserte RetailCRM det f\u00f8rste tredjepartsbiblioteket for tilgang til v\u00e5rt API. Det ble ganske aktivt brukt, samtidig som populariteten til tjenesten generelt vokste, og belastningen p\u00e5 API-et \u00f8kte raskere enn belastningen p\u00e5 webgrensesnittet. En gang ble veksten til et sjokk. <\/p>\n

    \"Wrote
    \n
    \n\"Wrote
    \n
    \nOg dette sjokket, som pilen til venstre viser, f\u00f8rte til fullstendig forbl\u00f8ffelse av serveren som betjente v\u00e5rt API. I en uke jobbet vi med \u00e5 finne ut hva som for\u00e5rsaket denne belastningen. Det viste seg at det var nettopp de foresp\u00f8rslene som ble sendt til v\u00e5rt API fra klientenes fronter. Rundt 50 klienter skapte belastningen. Her inns\u00e5 vi en av v\u00e5re feil \u2013 den totale mangelen p\u00e5 grenser. <\/p>\n

    Som et resultat innf\u00f8rte vi en grense for antall samtidige foresp\u00f8rsel. Fra en konto ble det n\u00e5 tillatt \u00e5 \u00e5pne maksimalt to foresp\u00f8rsel samtidig. Dette er tilstrekkelig for \u00e5 jobbe i replikasjonsmodus for datautveksling i batchmodus. De som ville bruke oss som backend, m\u00e5tte fra dette punktet mer tilpasse seg prisplanene, ettersom de innf\u00f8rte arbeid med flere kontoer i programvaren sin.<\/p>\n

    Orden i rekken<\/h2>\n

    \nAllerede fra 2014 ble ettersp\u00f8rselen etter det eksisterende API-et en viktig del av virksomheten, og API-et genererte den st\u00f8rste datamengden i datautveksling med kundene. I 2015 startet vi et prosjekt for \u00e5 rydde opp i API-et. Vi valgte JSON som format i stedet for XML og begynte \u00e5 bygge det p\u00e5 grunnlag av de egenskapene vi avdekket under implementeringen av den forrige versjonen:<\/p>\n

      \n
    1. Muligheten til \u00e5 administrere versjoner. Versjonering gj\u00f8r det mulig \u00e5 utvikle en ny versjon uten \u00e5 ber\u00f8re eksisterende applikasjoner og uten \u00e5 forstyrre brukerne. <\/li>\n
    2. Muligheten for brukeren \u00e5 se metadata i svaret han f\u00e5r.<\/li>\n
    3. Muligheten til \u00e5 utveksle store dokumenter. N\u00e5r vi behandler et dokument med flere enn 4-5 tusen poster, blir det et problem for serveren: lange transaksjoner, lange http-foresp\u00f8rsel. Vi har bygget en spesialmekanisme som lar oss oppdatere dokumentet del for del og h\u00e5ndtere individuelle poster i dette dokumentet ved \u00e5 sende dem til serveren.<\/li>\n
    4. Verkt\u00f8y for replikasjon \u2013 var ogs\u00e5 i forrige versjon.<\/li>\n
    5. Belastningsgrenser \u2013 som et resultat av problemene vi st\u00f8tte p\u00e5 i forrige versjon. Vi innf\u00f8rte grenser for antall foresp\u00f8rsel innen en tidsramme, antall parallelle foresp\u00f8rsel og foresp\u00f8rsel fra \u00e9n ip-adresse.<\/li>\n<\/ol>\n

      \nSiden da har vi utgitt to mindre versjoner av API-et og lansert flere spesialiserte API-er, men generelt har tiln\u00e6rmingen forblitt uendret. Den oppdaterte utvekslingsformatet og den nye arkitekturen har gjort det mulig \u00e5 rette opp mangler i API-et mye raskere.<\/p>\n

      API-en til MinLager i dag<\/h2>\n

      \nI dag l\u00f8ser API-en til MinLager mange oppgaver:<\/p>\n