{"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\/sv\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"Skrivna API \u2014 spr\u00e4ngde XML (tv\u00e5)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Den f\u00f6rsta API:n f\u00f6r MojeLager lanserades f\u00f6r 10 \u00e5r sedan. Under hela denna tid har vi arbetat med befintliga versioner av API:t och utvecklat nya. Flera versioner av API:t har redan blivit f\u00f6r\u00e5ldrade. <\/p>\n

I den h\u00e4r artikeln finns det mycket att ta upp: hur vi skapade API:t, varf\u00f6r det beh\u00f6vs f\u00f6r molntj\u00e4nsten, vad det ger anv\u00e4ndarna, vilka fallgropar vi har st\u00f6tt p\u00e5 och vad vi vill g\u00f6ra fram\u00f6ver.
\n<\/a><\/noindex>
\nJag heter Oleg Alekseev oalexeev<\/a><\/noindex>, jag \u00e4r teknisk chef och medgrundare av MojeLager. <\/p>\n

Varf\u00f6r g\u00f6ra ett API f\u00f6r tj\u00e4nsten<\/h2>\n

\nV\u00e5ra kunder, som best\u00e5r av tiotusentals entrepren\u00f6rer, anv\u00e4nder aktivt molnl\u00f6sningar: banktj\u00e4nster, n\u00e4tbutiker, lagerhantering, CRM. N\u00e4r man ansluter till en tj\u00e4nst \u00e4r det sv\u00e5rt att stoppa d\u00e4r. Och nu g\u00f6r den femte, \u00e5ttonde, tionde tj\u00e4nsten arbetet enklare f\u00f6r entrepren\u00f6ren, men data mellan dessa molntj\u00e4nster \u00f6verf\u00f6rs manuellt av anv\u00e4ndarna. Arbetet blir en mardr\u00f6m.<\/p>\n

Den uppenbara l\u00f6sningen \u00e4r att ge anv\u00e4ndarna m\u00f6jlighet att \u00f6verf\u00f6ra data mellan molntj\u00e4nster. Till exempel att importera och exportera data som filer, som sedan kan laddas upp till den \u00f6nskade tj\u00e4nsten. Filerna anpassas vanligtvis till formatet f\u00f6r varje tj\u00e4nst. Detta \u00e4r mer eller mindre enkelt manuellt arbete, men med antalet tj\u00e4nster som v\u00e4xer blir det allt mer komplicerat att utf\u00f6ra.<\/p>\n

S\u00e5 n\u00e4sta steg \u00e4r API:t. Med det vinner molntj\u00e4nsten p\u00e5 att koppla ihop flera tj\u00e4nster p\u00e5 en och samma plats. Framv\u00e4xten av ett s\u00e5dant ekosystem attraherar nya kunder tack vare ytterligare m\u00f6jligheter. En produkt med nya funktioner blir mer l\u00f6nsam och anv\u00e4ndbar.<\/p>\n

Om man skapar egna API:er, drar det till sig externa f\u00f6rs\u00e4ljare som programmerare som k\u00e4nner till din produkt tack vare API:t. De b\u00f6rjar bygga l\u00f6sningar baserade p\u00e5 API:t och tj\u00e4nar pengar p\u00e5 att automatisera sina kunders uppgifter.<\/p>\n

Redovisningssystemet f\u00f6r MojeLager bygger p\u00e5 enkla processer. Det centrala \u00e4r att arbeta med prim\u00e4ra dokument, m\u00f6jligheten att hantera mottagning och avskickning av varor, och att f\u00e5 rapporter f\u00f6r verksamheten baserat p\u00e5 dessa dokument. Det finns \u00e4ven data\u00f6verf\u00f6ring, till exempel till molnbaserad bokf\u00f6ring, och att f\u00e5 data fr\u00e5n banksystem eller detaljhandelspunkter. Dessutom arbetar vi med n\u00e4tbutiker: vi f\u00e5r information om produkter och skickar data om lagret.<\/p>\n

\"Skrivna
\n<\/p>\n

F\u00f6rsta API:et f\u00f6r MojeSkalad<\/h2>\n

\nUnder de 10 \u00e5r som MojeSkalad har arbetat med API:er har vi byggt upp olika integrationer som l\u00e5ter oss utbyta data, arbeta med banker, genomf\u00f6ra betalningar och anv\u00e4nda extern telefoni.<\/p>\n

Under det f\u00f6rsta \u00e5ret gjorde vi det m\u00f6jligt att exportera alla data i XML-format. D\u00e5 var det mycket mer f\u00f6rst\u00e5eligt och bekv\u00e4mt f\u00f6r anv\u00e4ndarna att ha data offline ist\u00e4llet f\u00f6r i n\u00e5gon typ av moln, och vi gav dem den m\u00f6jligheten. Exporten initierades genom manuell export fr\u00e5n gr\u00e4nssnittet. S\u00e5 det gick \u00e4nnu inte att kalla det f\u00f6r ett API. <\/p>\n

Samma \u00e5r b\u00f6rjade vi samarbeta med f\u00f6retaget Rusagro \u2014 de anv\u00e4nde redan en \"vuxen\" ERP f\u00f6r produktions- och f\u00f6rs\u00e4ljningsplanering, medan de automatiserade lastningen av vagnar p\u00e5 fabrikerna i MojeSkalad. S\u00e5 vi fick v\u00e5ra f\u00f6rsta embryo av ett riktigt API: utbytet mellan v\u00e5r tj\u00e4nst och ERP:n skedde genom att skicka en stor fil med data f\u00f6r alla typer av dokument. <\/p>\n

Detta var en bra l\u00f6sning f\u00f6r batchdatautbyte, men tillsammans med dokumenten var vi tvungna att \u00f6verf\u00f6ra deras beroenden: information om varor, motparter och lager. En s\u00e5dan samling \u00e4r inte sv\u00e5r att generera vid export, men ganska sv\u00e5r att bearbeta vid import, eftersom all information kommer i ett paket: b\u00e5de om nya dokument och redan existerande.<\/p>\n

Det f\u00f6rsta XML API:et levde inte l\u00e4nge \u2014 efter tv\u00e5 \u00e5r b\u00f6rjade vi bygga om det. Redan i b\u00f6rjan av dess drift gjorde vi flera misstag vid utformningen av det programmeringsgr\u00e4nssnittet.<\/p>\n

\"Skrivna
\nS\u00e5 h\u00e4r gjordes XML API:et: en illustration av en av v\u00e5ra arkitekter. F\u00f6rresten, se fram emot hans artiklar.<\/i><\/p>\n

H\u00e4r \u00e4r v\u00e5ra huvudmisstag:<\/p>\n

    \n
  1. JAXB-m\u00e4rkningen gjordes direkt p\u00e5 entity beans. F\u00f6r att kommunicera med databasen anv\u00e4nder vi Hibernate, och denna JAXB-m\u00e4rkning gjordes ocks\u00e5 p\u00e5 dessa b\u00f6nor. Detta misstag uppenbarade sig n\u00e4stan omedelbart: varje uppdatering av databasstrukturen kr\u00e4vde ett akut meddelande till alla som anv\u00e4nder API:et, eller att bygga tempor\u00e4ra l\u00f6sningar f\u00f6r att s\u00e4kerst\u00e4lla kompatibilitet med den tidigare databasstrukturen.<\/li>\n
  2. API utvecklades som ett slags till\u00e4gg, och vi definierade ursprungligen inte vilken del av produkten det utgjorde. Vi t\u00e4nkte inte heller p\u00e5 huruvida API:t var n\u00e5got viktigt, eller om vi beh\u00f6vde st\u00f6dja bak\u00e5tkompatibilitet f\u00f6r de f\u00f6rsta kunderna. Under en tid utgjorde antalet API-anv\u00e4ndare cirka 5 % av det totala lilla antalet, och vi uppm\u00e4rksammade dem inte. Den universella filtrering som gjordes vid den tiden ledde till att vi b\u00f6rjade anv\u00e4ndas som backend. Denna filtrering var inte riktigt GraphQL, men n\u00e5got liknande \u2013 den fungerade genom en m\u00e4ngd parametrar i fr\u00e5gestr\u00e4ngen. Med ett s\u00e5 kraftfullt verktyg var det sv\u00e5rt f\u00f6r anv\u00e4ndare att h\u00e5lla sig borta, och f\u00f6rfr\u00e5gningar b\u00f6rjade skickas direkt fr\u00e5n UI:n i deras e-handelsbutiker. Situationen blev en obehaglig \u00f6verraskning, eftersom tillhandah\u00e5llandet av en s\u00e5dan tj\u00e4nst skulle kr\u00e4va en annan priss\u00e4ttning och \u00f6verhuvudtaget en annan f\u00f6rst\u00e5else av API:t som produkt.<\/li>\n
  3. Eftersom API:t inte utvecklades som en huvudprodukt, producerades och publicerades dokumentationen om API:t som en biprodukt \u2013 genom reverse engineering. Denna v\u00e4g verkar ganska enkel och bekv\u00e4m, men den strider mot kontraktsarbetet. Det handlar om att ha en komponent med en f\u00f6rutbest\u00e4md arbetsmodell. Utvecklaren implementerar den enligt denna modell och uppgift, komponenten genomg\u00e5r tester, och kunden f\u00e5r en produkt som \u00f6verensst\u00e4mmer med analytikerns avsikt. \u00c5 andra sidan sl\u00e4pper reverse engineering en produkt p\u00e5 marknaden som helt enkelt finns: med provisoriska l\u00f6sningar, konstiga tillv\u00e4gag\u00e5ngss\u00e4tt och hemgjorda l\u00f6sningar ist\u00e4llet f\u00f6r den \u00f6nskade funktionaliteten. <\/li>\n
  4. Hela fl\u00f6det av f\u00f6rfr\u00e5gningar som kom genom API:t kunde bara analyseras som en logg fr\u00e5n Nginx eller applikationsservern. Detta gjorde det om\u00f6jligt att s\u00e4rskilja \u00e4mnesomr\u00e5den, f\u00f6rutom att bryta ner efter anv\u00e4ndare och prenumeranter. Om det inte finns m\u00f6jlighet att reglera registrering av applikationer eller kunder blir det om\u00f6jligt att analysera situationen. Detta problem p\u00e5verkade utvecklingen av API:t i minsta m\u00e5n; det handlar mer om att f\u00f6rst\u00e5 dess efterfr\u00e5gan och funktionalitet.<\/li>\n<\/ol>\n

    <\/p>\n

    F\u00f6rs\u00f6k nummer tv\u00e5: REST API<\/h2>\n

    \n\u00c5r 2010 f\u00f6rs\u00f6kte vi bygga ett utbytesystem med online-bokf\u00f6ringen \u2013 BukhSoft. Det gick inte v\u00e4gen. Men under integrationsprocessen uppstod en fullfj\u00e4drad API: en REST-tj\u00e4nst f\u00f6r utbyte som inte hade n\u00e5gra avvikelser som RPC-anrop. All kommunikation med API:et var f\u00f6renad med det standardiserade REST-l\u00e4get: i f\u00f6rfr\u00e5gningsstr\u00e4ngen finns entitetens namn och operationen som g\u00f6rs med den anges med hj\u00e4lp av HTTP-metoden. Vi la till filtrering baserat p\u00e5 senaste uppdatering av entiteter, s\u00e5 att anv\u00e4ndarna fick m\u00f6jlighet att bygga replikering med sina system.<\/p>\n

    Samma \u00e5r lanserades API:t f\u00f6r att exportera lager och produktbeholdningar. F\u00f6r anv\u00e4ndarna blev de mest v\u00e4rdefulla delarna av systemet tillg\u00e4ngliga via API:et \u2013 utbyte av prim\u00e4ra dokument och ber\u00e4kningsdata om lagerniv\u00e5er och varukostnader.<\/p>\n

    I december 2015 publicerade RetailCRM det f\u00f6rsta tredjepartsbiblioteket f\u00f6r \u00e5tkomst till v\u00e5rt API. Det b\u00f6rjade anv\u00e4ndas ganska aktivt, och samtidigt v\u00e4xte tj\u00e4nstens popularitet som helhet, belastningen p\u00e5 API:et \u00f6kade snabbare \u00e4n belastningen p\u00e5 webbgr\u00e4nssnittet. En dag f\u00f6rvandlades tillv\u00e4xten till en belastningsspik. <\/p>\n

    \"Skrivna
    \n
    \n\"Skrivna
    \n
    \nOch denna spik, som visar den v\u00e4nstra indikatoren, l\u00e4mnade servern som hanterade v\u00e5rt API i fullst\u00e4ndig f\u00f6rundran. Vi k\u00e4mpade i en vecka f\u00f6r att ta reda p\u00e5 vilken belastning som egentligen genererade detta. Det visade sig vara de beg\u00e4rningar som vidarebefordrades till v\u00e5rt API fr\u00e5n kundernas front-end. Ungef\u00e4r 50 kunder orsakade hela lasten. H\u00e4r ins\u00e5g vi ett av v\u00e5ra misstag \u2013 den fullst\u00e4ndiga avsaknaden av gr\u00e4nser. <\/p>\n

    Som ett resultat inf\u00f6rde vi en gr\u00e4ns f\u00f6r antalet samtidiga f\u00f6rfr\u00e5gningar. Fr\u00e5n ett konto gick det nu att \u00f6ppna h\u00f6gst tv\u00e5 f\u00f6rfr\u00e5gningar samtidigt. Detta \u00e4r tillr\u00e4ckligt f\u00f6r att arbeta i replikationsl\u00e4ge f\u00f6r datautbyte i batchl\u00e4ge. De som ville anv\u00e4nda oss som backend var nu tvungna att mer anpassa sig till priss\u00e4ttningarna, eftersom de b\u00f6rjade implementera arbete med flera konton i sina programverktyg.<\/p>\n

    Vi s\u00e4tter i ordning<\/h2>\n

    \nRedan fr\u00e5n 2014 blev efterfr\u00e5gan p\u00e5 det befintliga API:t en viktig del av verksamheten, och sj\u00e4lva API:t genererade den st\u00f6rsta m\u00e4ngden data i datautbytet med kunder. \u00c5r 2015 startade vi projektet med att s\u00e4tta API:t i ordning. Vi valde JSON som format ist\u00e4llet f\u00f6r XML och b\u00f6rjade bygga det baserat p\u00e5 de insikter vi fick vid implementeringen av den tidigare versionen:<\/p>\n

      \n
    1. M\u00f6jlighet att hantera versioner. Versionshantering g\u00f6r det m\u00f6jligt att utveckla en ny version utan att p\u00e5verka den befintliga applikationen och utan att st\u00f6ra anv\u00e4ndarna. <\/li>\n
    2. M\u00f6jlighet f\u00f6r anv\u00e4ndaren att se metadata i sj\u00e4lva svaret som han f\u00e5r.<\/li>\n
    3. M\u00f6jlighet att byta stora dokument. Om vi hanterar ett dokument med fler \u00e4n 4-5 tusen poster blir det ett problem f\u00f6r servern: l\u00e5ng transaktion, l\u00e5ng http-f\u00f6rfr\u00e5gan. Vi har byggt en speciell mekanism som g\u00f6r det m\u00f6jligt att uppdatera dokumentet i delar och hantera individuella poster i detta dokument genom att skicka dem till servern.<\/li>\n
    4. Verktyg f\u00f6r replikering \u2013 fanns \u00e4ven i tidigare version.<\/li>\n
    5. Belastningsgr\u00e4nser \u2013 som ett arv av problemen vi st\u00f6tte p\u00e5 i den tidigare versionen. Vi inf\u00f6rde gr\u00e4nser f\u00f6r antalet f\u00f6rfr\u00e5gningar under en viss tidsperiod, antalet parallella f\u00f6rfr\u00e5gningar och f\u00f6rfr\u00e5gningar fr\u00e5n en och samma ip-adress.<\/li>\n<\/ol>\n

      \nSedan dess har vi sl\u00e4ppt tv\u00e5 mindre versioner av API:et och lanserat flera specialiserade API:er, men \u00f6vergripande angreppss\u00e4tt har f\u00f6rblivit of\u00f6r\u00e4ndrat. Den uppdaterade utbytesformatet och den nya arkitekturen har m\u00f6jliggjort att \u00e5tg\u00e4rda brister i API:et mycket snabbare.<\/p>\n

      API f\u00f6r MinLager idag<\/h2>\n

      \nIdag l\u00f6ser API f\u00f6r MinLager m\u00e5nga uppgifter:<\/p>\n