{"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\/da\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"Skriver API \u2014 smadrer XML (to)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Den f\u00f8rste API fra MitLager blev lanceret for 10 \u00e5r siden. I hele denne tid har vi arbejdet p\u00e5 de eksisterende versioner af API'et og udviklet nye. Og flere versioner af API'et er allerede blevet begravet. <\/p>\n

I denne artikel vil der v\u00e6re meget: hvordan API'et blev skabt, hvorfor det er n\u00f8dvendigt for cloudtjenesten, hvad det giver brugerne, hvilke udfordringer vi har m\u00f8dt, og hvad vi \u00f8nsker at g\u00f8re fremadrettet.
\n<\/a><\/noindex>
\nMit navn er Oleg Alekseev oalexeev<\/a><\/noindex>, jeg er teknisk direkt\u00f8r og medstifter af MitLager. <\/p>\n

Hvorfor lave API til servicen<\/h2>\n

\nVores kunder, som er titusindvis af iv\u00e6rks\u00e6ttere, bruger aktivt cloudl\u00f8sninger: banktjenester, webshops, vareh\u00e5ndtering, CRM. N\u00e5r man f\u00f8rst er tilsluttet \u00e9n, er det allerede sv\u00e6rt at stoppe. Og s\u00e5 er der den femte, ottende, tiende tjeneste, der g\u00f8r iv\u00e6rks\u00e6tterens arbejde lettere, men brugerne overf\u00f8rer stadig data mellem disse cloudtjenester manuelt. Det bliver til et mareridt.<\/p>\n

Den \u00e5benlyse l\u00f8sning er at give brugerne mulighed for at overf\u00f8re data mellem cloudtjenester. For eksempel at importere og eksportere data som filer, der derefter kan uploades til den \u00f8nskede tjeneste. Filene tilpasses normalt formatet for hver tjeneste. Det er mere eller mindre et simpelt manuelt arbejde, men med stigende antal af disse tjenester bliver det blot sv\u00e6rere at udf\u00f8re.<\/p>\n

Derfor er det n\u00e6ste skridt \u2014 API. Med det vinder cloudtjenesten ved at forbinde flere tjenester p\u00e5 \u00e9t sted. Fremkomsten af et s\u00e5dant \u00f8kosystem tiltr\u00e6kker nye kunder p\u00e5 grund af de ekstra muligheder. Et produkt med nye funktioner bliver mere attraktivt og nyttigt.<\/p>\n

Hvis man laver egne programmeringsgr\u00e6nseflader, tiltr\u00e6kker det eksterne s\u00e6lgere i form af programm\u00f8rer, der kender dit produkt gennem API'et. De begynder at bygge l\u00f8sninger baseret p\u00e5 det foresl\u00e5ede API og tjener penge p\u00e5 at automatisere deres kunders opgaver.<\/p>\n

Mit MyStocks regnskabssystem bygger p\u00e5 enkle processer. Det vigtigste er arbejdet med prim\u00e6re dokumenter, muligheden for at modtage og afsende varer, samt at f\u00e5 rapporter til virksomheden baseret p\u00e5 disse dokumenter. Derudover er der dataoverf\u00f8rsel, f.eks. til cloud-bogholderi, og modtagelse af data fra banksystemer eller detailpunkter. Vi arbejder ogs\u00e5 med internetbutikker: vi modtager oplysninger om varer og sender data om lagerbeholdninger.<\/p>\n

\"Skriver
\n<\/p>\n

Den f\u00f8rste API fra MyStocks<\/h2>\n

\nI l\u00f8bet af de 10 \u00e5r, hvor MyStocks har arbejdet med API, har vi opbygget mange integrationer, der muligg\u00f8r dataudveksling, bankbehandling, betalinger og brugen af ekstern telefoni.<\/p>\n

I det f\u00f8rste \u00e5r gjorde vi det muligt at eksportere enhver data i XML-format. P\u00e5 det tidspunkt var det meget nemmere og mere sikkert for brugerne at holde data offline end i en eller anden sky, og vi gav dem denne mulighed. Eksporten blev startet manuelt fra gr\u00e6nsefladen. S\u00e5 API kunne man ikke kalde det endnu. <\/p>\n

Dengang begyndte vi ogs\u00e5 samarbejde med Rusagro \u2014 de brugte allerede en 'moden' ERP til planl\u00e6gning af produktion og salg, men automatiserede lastningen af vognene p\u00e5 fabrikkerne med MyStocks. S\u00e5ledes fik vi de f\u00f8rste sp\u00e6de skridt hen imod et rigtigt API: udvekslingen mellem vores service og ERP-en fandt sted ved at sende en stor fil med data om alle dokumenttyper. <\/p>\n

Dette er en god l\u00f8sning til batchdataudveksling, men sammen med dokumenterne m\u00e5tte afh\u00e6ngigheder overf\u00f8res: oplysninger om varer, kunder og lagre. S\u00e5dan en sammenblanding er ikke sv\u00e6r at generere ved eksport, men ret sv\u00e6r at afkode ved import, da alle oplysninger kommer i en pakke: b\u00e5de om nye dokumenter og om eksisterende.<\/p>\n

Den f\u00f8rste XML API levede ikke l\u00e6nge \u2014 efter to \u00e5r begyndte vi at ombygge den. Allerede fra starten af dens drift gjorde vi flere fejl i opbygningen af det programmerbare interface.<\/p>\n

\"Skriver
\nS\u00e5dan blev XML API bygget: illustration fra en af vores arkitekter. For \u00f8vrigt, hold \u00f8je med hans artikler.<\/i><\/p>\n

Her er vores hovedfejl:<\/p>\n

    \n
  1. JAXB-annoteringen blev lavet direkte p\u00e5 entitetsb\u00f8nner. For at kommunikere med databasen bruger vi Hibernate, og de samme b\u00f8nner blev annoteret med JAXB. Denne fejl dukker n\u00e6sten med det samme op: enhver opdatering af datagrundlaget f\u00f8rte til behovet for straks at informere alle, der bruger API'et, eller konstruktion af hurtige l\u00f8sninger, der kunne sikre kompatibilitet med den tidligere datastruktur.<\/li>\n
  2. API'et opstod som en slags supplement, og oprindeligt definerede vi ikke, hvilken del af produktet det udg\u00f8r. Vi overvejede heller ikke, om API'et var noget vigtigt, og om det var n\u00f8dvendigt at opretholde bagudkompatibilitet for de f\u00f8rste kunder. P\u00e5 et tidspunkt udgjorde antallet af API-brugere omkring 5% af det samlede lille antal, og vi gav dem ikke meget opm\u00e6rksomhed. Den universelle filtrering, vi tidligere havde lavet, f\u00f8rte til, at vi blev brugt som backend. Denne filtrering var slet ikke GraphQL, men noget i den stil \u2014 den fungerede gennem en masse parametre i foresp\u00f8rgselsstrengen. Med et s\u00e5 kraftigt v\u00e6rkt\u00f8j var det sv\u00e6rt for brugerne at holde sig v\u00e6k, og foresp\u00f8rgslerne blev sendt direkte fra deres e-handelsplatforms brugergr\u00e6nseflade. Situationen blev en ubehagelig overraskelse, fordi levering af en s\u00e5dan tjeneste burde kr\u00e6ve en anden priss\u00e6tning og generelt en anden forst\u00e5else af selve API'et som produkt.<\/li>\n
  3. Fordi API'et ikke udviklede sig som et hovedprodukt, blev dokumentationen til API'et udarbejdet og offentliggjort som en restl\u00f8sning \u2014 gennem reverse engineering. Denne metode synes at v\u00e6re temmelig enkel og praktisk, men strider imod arbejde efter kontrakt. Det er, n\u00e5r der er en bestemt komponent med en foruddefineret arbejdsgang. Udvikleren implementerer den i overensstemmelse med denne skitse og opgaven, komponenten gennemg\u00e5r testning, kunden f\u00e5r et produkt, der svarer til analytikerens intentioner. Reverse engineering kaster derimod et produkt ud p\u00e5 markedet, som bare findes: med hurtige l\u00f8sninger, m\u00e6rkelige beslutninger og un\u00f8dvendige funktionaliteter i stedet for den \u00f8nskede funktionalitet. <\/li>\n
  4. Hele str\u00f8mmen af foresp\u00f8rgsler, der kom gennem API'en, kunne kun analyseres som en Nginx-log eller fra applikationens server. Dette gjorde det umuligt at identificere emneomr\u00e5der, bortset fra at opdele efter brugere og abonnenter. Hvis der ikke er mulighed for at regulere registreringen af applikationen eller kunderne, bliver det umuligt at analysere situationen. Dette problem havde mindst indflydelse p\u00e5 udviklingen af API'en; det handlede mere om at forst\u00e5 dens eftersp\u00f8rgsel og funktionsindhold.<\/li>\n<\/ol>\n

    <\/p>\n

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

    \nI 2010 fors\u00f8gte vi at opbygge et udvekslingssystem med online regnskabsprogrammet \u2013 BuchSoft. Det lykkedes ikke. Men i integrationsprocessen blev der skabt et komplet API: en REST-udvekslingstjeneste, hvor der ikke var friheder som kald til operationer i form af RPC-opkald. Al kommunikation med API'en blev standardiseret til REST-formatet: foresp\u00f8rgselslinjen indeholder navnet p\u00e5 entiteten, og den operation, der udf\u00f8res, bestemmes ved hj\u00e6lp af HTTP-metoden. Vi tilf\u00f8jede filtrering efter opdateringstidspunktet for entiteterne, hvilket gav brugerne mulighed for at bygge replikation med deres egne systemer.<\/p>\n

    I samme \u00e5r blev der introduceret et API til eksport af lager- og varelagerdata. Gennem API'en blev de mest v\u00e6rdifulde dele af systemet tilg\u00e6ngelige for brugerne \u2013 udveksling af prim\u00e6re dokumenter og beregningsdata vedr\u00f8rende lagrene og omkostningerne af varer.<\/p>\n

    I december 2015 offentliggjorde RetailCRM det f\u00f8rste tredjepartsbibliotek til adgang til vores API. Det blev brugt aktivt, samtidig voksede tjenestens popularitet generelt, og belastningen p\u00e5 API'en voksede hurtigere end belastningen p\u00e5 webgr\u00e6nsefladen. En dag blev v\u00e6ksten til en belastningsspid. <\/p>\n

    \"Skriver
    \n
    \n\"Skriver
    \n
    \nOg denne spid, som pilen til venstre viser, for\u00e5rsagede total forbl\u00f8ffelse hos serveren, der betjente vores API. I en uge pr\u00f8vede vi at finde ud af, hvad pr\u00e6cist denne belastning genererede. Det viste sig, at det var de samme foresp\u00f8rgsler, der blev transmitteret til vores API fra frontend'en hos kunderne. Omkring 50 kunder stod for det hele. Her inds\u00e5 vi en af vores fejl \u2013 fuldst\u00e6ndig mangel p\u00e5 gr\u00e6nser. <\/p>\n

    Som f\u00f8lge heraf har vi indf\u00f8rt en gr\u00e6nse for antallet af samtidige foresp\u00f8rgsler. Fra \u00e9n konto kan man nu \u00e5bne h\u00f8jst to foresp\u00f8rgsler ad gangen. Det er tilstr\u00e6kkeligt til at arbejde i reproduktionsmode for dataudveksling i batchmode. De, der \u00f8nskede at bruge os som backend, m\u00e5tte \u00f8ge deres overensstemmelse med priserne, da de indf\u00f8rte brugen af flere konti i deres software.<\/p>\n

    Bringer orden<\/h2>\n

    \nSiden 2014 er eftersp\u00f8rgslen efter den eksisterende API blevet en vigtig del af forretningen, og selve API'en har genereret den st\u00f8rste m\u00e6ngde data i udvekslingen med kunderne. I 2015 lancerede vi projektet for at bringe API'en i orden. Vi valgte JSON som format i stedet for XML og begyndte at bygge det ud fra de funktioner, vi havde identificeret ved implementeringen af den tidligere version:<\/p>\n

      \n
    1. Mulighed for versionering. Versionering g\u00f8r det muligt at udvikle en ny version uden at p\u00e5virke den eksisterende applikation og uden at forstyrre brugerens arbejde. <\/li>\n
    2. Mulighed for brugeren at se metadata i svaret, som de modtager.<\/li>\n
    3. Mulighed for at udveksle store dokumenter. Hvis vi behandler et dokument med mere end 4-5 tusinde poster, bliver det et problem for serveren: lange transaktioner, lange http-foresp\u00f8rgsler. Vi har bygget en s\u00e6rlig mekanisme, der muligg\u00f8r at opdatere dokumentet i dele og h\u00e5ndtere individuelle poster i dokumentet ved at sende dem til serveren.<\/li>\n
    4. V\u00e6rkt\u00f8jer til replikation - der var ogs\u00e5 i den tidligere version.<\/li>\n
    5. Belastningsgr\u00e6nser - som et resultat af tidligere problemer, som vi st\u00f8dte p\u00e5 i den tidligere version. Vi har indf\u00f8rt gr\u00e6nser for antal foresp\u00f8rgsler i en given tidsramme, antal parallelle foresp\u00f8rgsler og foresp\u00f8rgsler fra \u00e9n ip-adresse.<\/li>\n<\/ol>\n

      \nSiden da har vi udgivet to mindre versioner af API'en og lanceret flere specialiserede API'er, men den overordnede tilgang er forblevet u\u00e6ndret. Den opdaterede udvekslingsformat og den nye arkitektur har gjort det muligt at rette mangler i API'en hurtigere.<\/p>\n

      API'en fra MojeLager i dag<\/h2>\n

      \nI dag l\u00f8ser API'en fra MojeLager mange opgaver:<\/p>\n