Linköpings universitetSE–581 83 Linköping

013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 16hp | Datateknik

2017 | LIU-IDA/LITH-EX-G--17/054--SE

En prestandastudie på JSON-och XML-formaterad API-dataA performance study on JSON- and XML-formatted API-data

Andreas Larsson

Handledare : Anders FröbergExaminator : Anders Fröberg

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrån publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

© Andreas Larsson

Abstract

This paper aims to analyze the effects different data representation techniques have onthe API generating the data, and the client receiving and processing it. For this purpose,the formats JSON and XML was chosen. In order to analyze the effects, an API wasdeveloped in order to generate realistic results. A simple client JavaScript website wascreated which requested the API for data in which it processed its response to a JSON- orXML-object depending on which test was conducted. The tests were separated in two sce-narios, where the used dataset was large or small respectively, represented in either JSONor XML. The client logged the time it took from the test’s beginning until all responses hadbeen processed. The API-server measured the time it took from receiving the request untilit was returned, as well as the system’s CPU- and virtual-memory usage.

The study found that JSON-formatted data overall resulted in a more efficient opera-tion. In all test cases the processing time for both the client and server were smaller forthe JSON-formatted data. However, for small datasets, the study showed that the XML-formatted data used a marginally smaller portion of the system’s resources, although theJSON-formatted data was still processed quicker.

Sammanfattning

Den här rapporten avser undersöka effekterna olika representationsmetoder av sammadata har på det API som genererar datan, samt klienten som tar emot och bearbetar den.För syftet har formaten JSON och XML valts. För att analysera påverkan på API:et ochklienten utvecklades ett API för att testerna skulle ge realistiska resultat. En enkel klien-themsida i JavaScript utvecklades vars uppgift var att begära data från API:et som sedanbearbetades till JSON- eller XML-objekt beroende på vilket test som kördes. Testerna sep-arerades i två scenarion, där datamängden för de två scenarierna var stor respektive liten,representerat som JSON eller XML. Klienten loggade den tid det tog från att programmetstartades till att samtliga svar hade bearbetats. API-servern mätte den tid det tog från attservern mottog klientens förfrågan till att ett svar var redo att returneras. Servern mätteockså systemets CPU- och minnesanvändning.

Studien visade att JSON-formaterad data överlag resulterade i en mer effektiv operation.I samtliga testfall var bearbetningstiden för både klient och API-server lägre för JSON-formaterad data. Däremot visade testerna också att XML-formaterad data förbrukade enmarginellt mindre andel av systemets resurser vid bearbetning av små datamängder. Församma testfall var dock bearbetningstiden av den JSON-formaterade datan fortfarandelägre.

iv

Förord

Jag vill tacka SysPartner AB med medarbetare för att tagit migunder sina vingar och tillåtit mig att applicera min utbildning pånågot praktiskt. Samtliga medarbetare har ställt upp för att göramin närvaro bekväm och erbjudit kompetens inom områden som för migvarit obekanta. Jag vill särskilt tacka Marcus Hedberg som varitmin handledare på företaget och avvarat sin dyrbara tid till atthjälpa mig komma igång och driva arbetet framåt. Jag vill dessutomtacka Simon Skogh för sin vänskapliga närvaro och erbjudandet av sinkompetens i de system som jag har arbetat med under arbetets gång.

Jag vill också tacka Anders Fröberg som har agerat både handledareoch examinator för mitt arbete. Anders har hjälpt mig att omformuleraen idé till ett examensarbete, och har under arbetets gång biståttmed den handledning som gjort mitt examensarbete möjligt.

Slutligen vill jag tacka Philip Johansson och Niklas Blomqvist somvarit mina opponenter och erbjudit sina mycket hjälpsamma synpunkteroch konstruktiv kritik på mitt arbete.

v

Innehållsförteckning

Sammanfattning iii

Författarens tack v

Innehållsförteckning vi

Figurförteckning vii

1 Introduktion 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Bakgrund 22.1 Företaget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Teknologier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Teori 63.1 Datarepresentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Metod 84.1 Analys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Representationsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 Implementation 135.1 Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Representationsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Resultat 196.1 Scenario 1 - Stora datamängder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Scenario 2 - Små datamängder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Diskussion 227.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.3 Studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.4 Källkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8 Slutsats 278.1 Framtida arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Bibliography 29

vi

Figurförteckning

3.1 Samling (array) och objekt (object) i JSON. Källa: www.json.org . . . . . . . . . . . 7

4.1 Databasdiagram över hårdvarubudgeten. . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Tabell över API:ets resurser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1 Lista över användare från API:et. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 Ett utdrag ur API:ets tidsberäkning. . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3 Ett utdrag ur API:ets hårdvarubudget. . . . . . . . . . . . . . . . . . . . . . . . . . . 165.4 Intranätets vy av tidsrapportering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.5 Tabell över filstorlekarna som används av testerna. . . . . . . . . . . . . . . . . . . 185.6 Specifikation av den testmiljö som testerna exekverats på. . . . . . . . . . . . . . . 18

6.1 Resultat av klientens tester för scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Stapeldiagram över klienttesternas resultat för scenario 1. . . . . . . . . . . . . . . . 206.3 Resultat av serverns (API:ets) bearbetning av förfrågningarna för scenario 1. . . . . 206.4 Resultat av klientens tester för scenario 2. . . . . . . . . . . . . . . . . . . . . . . . . 206.5 Stapeldiagram över klienttesternas resultat för scenario 2. . . . . . . . . . . . . . . . 216.6 Resultat av serverns (API:ets) bearbetning av förfrågningarna för scenario 2. . . . . 21

vii

1 Introduktion

1.1 Motivation

Isolerade datorsystem och tjänster har minskat både i antal och betydelse i takt med att mark-naden övergått och anpassats till service-oriented computing (SOC) [17, 13]. Denna övergånghar kommit att ta integrering av IT-system från en fas där mjukvara endast var beroende avsin egen existens för att fungera, till att i allt större utsträckning göra sig beroende av andraapplikationer och dess tjänster. Det handlar emellertid om att skapa program som utnyttjarwebbtjänster (web services) för att överföra, identifiera och modifiera resurser som överförsmed standardiserade kommunikationsmetoder över Internet [13]. En metodik för att imple-mentera web services är arkitekturen representational state transfer (REST, eller RESTful), sommyntades av Roy Fielding år 2000 [7]. REST är en samling principer som appliceras underutvecklingen och användningen av webbtjänster, och arkitekturen har fått stort genomslagdär den stod för 69 % av alla Web-API:er år 2014 [9]. Arkitekturen ställer inga krav på vilkenmetod man ska använda för att presentera informationen, varpå utvecklaren behöver göraett medvetet val i vilken eller vilka representationsmetoder denne vill att erbjuda. Olikarepresentationsmetoder påverkar dock både klient och server, och valet är därför inte alltidsjälvklart.

1.2 Syfte

Det här arbetet kommer att studera en befintlig implementation av ett intranät på företagetSysPartner AB. Med SysPartners intranät som utgångspunkt kommer ett nytt intranät attutvecklas som senare kommer att användas för att utvärdera olika val av representationsme-toder och hur de presterar på server- och klientsidan. Syftet är att hitta en optimal represen-tationsmetod för SysPartners ändamål för att undvika att det bildas flaskhalsar när informa-tionen ska förberedas, skickas, tas emot och bearbetas.

1.3 Frågeställningar

1. Vilken av representationsmetoderna JSON och XML ger bäst prestanda för ett API ochen klient med avseende på bearbetningstid och resursförbrukning?

1

2 Bakgrund

2.1 Företaget

Arbetet utförs hos SysPartner AB i Linköping. SysPartner är ett relativt ungt företag medsitt största kontor i Linköping, ett mindre kontor i Stockholm samt ett nystartat kontor iNorrköping. I Linköping har SysPartner i skrivande stund 20 anställda, och arbetar huvud-sakligen inom IT-sektorn där de utvecklar, driver och förvaltar företags IT-system.

SysPartner har ett intranät, som de själva underhåller, byggt på Drupal. Drupal är ettmodulärt CMS-system (content management system) som tillåter användarna att flexibelt bytaut moduler för att syftet ska passa dem, vilket uppnås genom att låta modulerna kommu-nicera med varandra via ett underliggande gränssnitt (interface). Det som SysPartner harupptäckt är att nivån av standardisering i Drupal gör det väldigt smidigt att lägga till ochta bort moduler i intranätet, medan det å andra sidan är svårt att utveckla egen funktion-alitet och anpassa systemet utöver vad Drupal redan erbjuder. SysPartner vill därför påsikt byta ut sitt intranät, och genom att erbjuda datahantering med ett API skulle de merflexibelt kunna experimentera med alternativa grafiska gränssnitt (front-end). Byggt på denidén uppstod syftet till arbetet, som kompletterats med en studie för att undersöka vilkenrepresentationsmetod som bäst lämpar sig att använda i API:et.

2.2 Teknologier

Hypertext transfer protocol (HTTP)

HTTP är ett protokoll för att överföra information mellan enheter på ett nätverk där enheterkan skicka förfrågningar (requests) till en annan enhet som kommer att returnera ett med-delande. Den enhet som begär information kallas i regel för klienten, och den besvarandeenheten för servern. En förfrågan innehåller bland annat information om vilken operationklienten avser göra på den resurs som URL:en (Uniform Resource Locator) pekar på. Ett urvalav dessa operationer är GET, PUT, POST och DELETE [16]. När en server svarar på en för-frågan kommer meddelandet bland annat innehålla en statuskod som indikerar hur serverntolkade förfrågan [16]. Statuskoden kan bland annat indikera att förfrågan bearbetades med

2

2.2. Teknologier

lyckat resultat (statuskod 200), eller om servern inte kunde finna den resurs som begärdes(statuskod 404).

Representational state transfer (REST)

REST är en arkitektur som begränsar utformningen och användningen av webbtjänster för attgöra systemet skalbart och tillgängligt [13]. Syftet med REST är att göra systemet simpelt ochenbart utnyttja grundläggande kommunikationstekniker. Genom att utveckla och användasystemet med minimala och grundläggande tekniker förebygger man behovet av speciellmjukvara för att använda tjänsten. För kommunikation förespråkar REST-arkitekturenanvändning av tillståndslös HTTP för att möjliggöra åtkomst med det enda kravet på Inter-netuppkoppling, vilket 53% av jordens befolkning innehar [8].

REST är alltså en arkitektur med principer som begränsar ett system för att det ska upp-fylla kraven som Roy Fielding presenterade i sin avhandling. Några av de kraven som RoyFielding presenterade följer nedan.

REST-arkitekturens viktigaste principer

Null style

Grundläggande för utveckling i enlighet med REST-arkitektur är att systemets behov finnsspecificerade. Dessa behov beaktas under utvecklingen av systemet och begränsningarnaappliceras successivt på ett sätt som påverkar systemet beteende i enlighet med REST:sprinciper [7].

Client-Server

Hela idén med REST är att det finns en klient som kommunicerar med en tjänst som kanbestå av en eller flera servrar. För att främja systemets skalbarhet, portabilitet och tillgäng-lighet oberoende av plattform separeras datahantering från användargränssnittet [7]. Dettatillåter de olika delarna i datahantering och användargränssnittet att utvecklas oberoende avvarandra.

Stateless

REST-baserade system är tillståndslösa och bygger på tillståndslös HTTP. Det innebär attsamtliga förfrågningar som sker från en klient till en server inte påverkas av de olika till-stånd som en klient kan befinna sig i [7]. Samtliga förfrågningar måste innehålla all informa-tion som är nödvändig för att servern ska kunna identifiera och returnera data, och servernkommer inte att beakta inom vilket tillstånd eller sammanhang klienten skickar sina för-frågningar. Kontrollen för vilka förfrågningar som ska skickas beroende på vilken position igränssnittets hierarki användaren befinner sig i hamnar således på användarens gränssnitt,och inte på servern. Till exempel så kommer inte servern att beakta vad användaren tidigarebegärt för resurser, eller vilken sida i det grafiska gränssnittet som användaren befinner sig i,när servern tolkar användarens förfrågningar.

Uniform Interface

Som nämnt ovan krävs det av klienten att förfrågningar innehåller all information för attunikt kunna identifiera resurser, vilket är en av de mest grundläggande av principerna iREST-arkitekturer. En resurs är information från servern som gjorts tillgänglig via ett en-hetligt gränssnitt (uniform interface) och som identifieras av en URI (uniform resource identifier).Den praxis som appliceras på gränssnittets design och användning handlar om att främja

3

2.2. Teknologier

identifiering av resurserna, manipulering av resurserna och låta resurserna vara självförk-larande. Till exempel så binder man en viss resurs till en logisk och relevant URI för att göraURI:en självförklarande. Tillgång till resurserna ges med hjälp av de inbyggda metodernai HTTP: GET, PUT, POST och DELETE. Dessa appliceras i HTTP-paketet som pekar på enURI.

GETURI Statuskod Beskrivningsyspartner.se/api/v1/users/ 200, 404 Returnerar en lista över användare.

syspartner.se/api/v1/users/123/ 200, 404Returnerar detaljerad vy över en specifik användareunikt identifierad av "123".

PUTURI Statuskod Beskrivning

syspartner.se/api/v1/users/123/ 200, 400, 404Modifierar användaren identifierad av "123" enligtden information som fanns i klientens förfrågan.

POSTURI Statuskod Beskrivning

syspartner.se/api/v1/users/ 201, 400, 404Skapar användaren enligt den information somfanns i klientens förfrågan.

DELETEURI Statuskod Beskrivningsyspartner.se/api/v1/users/123 204, 404 Raderar användaren identifierad av "123".

Tabell 3.1: Exempel på metoder att anropa till ett API.

Django REST framework

Django REST framework, hädanefter kallad Django REST, är ett ramverk som bygger påDjango Web Framework. Ramverket är skrivet i Python och erbjuder mer inbyggd funk-tionalitet än många andra ramverk. Det finns även möjlighet att lägga till extra funktionalitetvia tillägg om man är i behov av något som inte redan finns inbyggt i ramverket. DjangoWeb Framework erbjuder skalbara, säkra och snabba grunder att webbutveckla i [2], ochDjango REST har anpassat ramverket för att utveckla API:er [4]. Båda ramverken är mycketväl dokumenterade och gratis med öppen källkod.

Django Views

Enligt allmän accepterad etikett utvecklas serverns interface i en fil kallad "views.py". Djangoerbjuder inbyggd funktionalitet för att utveckla views, som är funktioner som tar emot ochreturnerar webbförfrågningar. Här finns den logik som bearbetar en klients förfrågan ochslutligen returnerar ett svar tillbaka, oavsett om det det är en hemsida, rådata, bild ellerannan information. För arbetets syfte kommer enbart rådata att returneras, och hur rådatanska se ut är vad som arbetet går ut på att utvärdera.

Django Models

Django Models är ett kraftfullt verktyg som används för att inom servern representera ochlagra data. Django Models är ett ORM-verktyg (object-relational mapping) som representerardatabastabeller som interna klasser, vilket underlättar serverns datalagring eftersom utveck-laren tillåts arbete med objekt istället för att exekvera ofiltrerade databasfrågor (queries).

4

2.2. Teknologier

Säkerhet

Att exponera intern data för Internet kan vara farligt, och säkerhetsindustrin är ständigtaktiv när det kommer till att identifiera och åtgärda sårbarheter i programvara och pro-tokoll. Django uppdateras ständigt i takt med att sårbarheter upptäcks, men utöver bristeri mjukvara som kan exponera känslig data behöver också utvecklaren vara medveten omde risker som finns. Sårbarheter uppstår inte nödvändigtvis för att programvara innehållersårbarheter, utan också för att utvecklare inte använder rätt metoder för att skydda sitt pro-gram. Django erbjuder inbyggda säkerhetsmetoder för att hjälpa utvecklaren skydda sig motden vanligaste typen av attacker. Till exempel så erbjuder redan Django Models inbyggdfunktionalitet för att filtrera den data som klienten bifogat i sin förfrågan innan informa-tionen slutligen sparas i databasen. Detta erbjuder ett säkert sätt att hantera data eftersomexekvering av ofiltrerade databasfrågor banar väg för sårbarheter som SQL-injektioner [18].Att använda Djangos förinstallerade funktionalitet är således ett förhållandevis säkert sätt attutveckla sin server på, men man bör dessutom undersöka Djangos rekommendationer ochutvärderingsverktyg innan okända klienter tillåts kommunicera med servern.

5

3 Teori

Teorikapitlet presenterar konceptet datarepresentation och de två format som har valts attstudera för detta arbete.

3.1 Datarepresentation

Fielding beskriver tre tillvägagångssätt för hur informationen ska representeras i enlighetmed REST [7]. Ett utav av tillvägagångssätten är att returnera rådata tillsammans med meta-data som beskriver informationen som skickats. De vanligaste metoderna för att presenterarådata är XML, JSON, HTML och ATOM [21]. Det här arbetet har begränsats till XML ochJSON och avser undersöka vilket av de två som presterar bäst i det färdiga intranätet somutvecklats för arbetet.

Extensible Markup Language (XML)

XML är ett format för att representera data som 1998 introducerades som en standard avW3C [10]. XML använder element och attribut för att representera information som en träd-struktur [10]. Nedan följer ett exempel på hur ett meddelande skulle kunna se ut om detrepresenterades som ett XML-träd.

<?xml version="1.0" encoding="UTF-8"?><message msg_id="10">

<header><subject>Message subject</subject><sender user_id="1">sender@email.com</sender><receiver user_id="2">receiver@email.com</receiver><date>8 Feb 2017</date>

</header><body>

This is a message!</body>

</message>

6

3.1. Datarepresentation

JavaScript Object Notation (JSON)

JSON är ett vanligt format som används för att representera data [10]. JSON beskriver datasom en samling eller ett objekt. En array (samling) börjar med “[“ och avslutas med “]”, ochde värden i samlingen separeras med ett kommatecken. Ett JSON-objekt är är en samling avpar innehållandes ett namn och ett värde och börjar med “{“ och avslutas med “}”. Varje namnföljs av ett kolon och värdet, och varje par av namn och värden separeras med kommatecken.

Figure 3.1: Samling (array) och objekt (object) i JSON. Källa: www.json.org

Nedan följer ett exempel på hur ett meddelande skulle kunna presenteras i JSON:

{"message_id": 10,"subject": "Message subject","sender": "sender@email.com","receiver": "receiver@email.com","date": "8 Feb 2017","content": "This is a message!"

}

Tidigare studier

Rapportens frågeställning handlar om att besvara huruvida representationen av den över-förda datan bör vara i JSON- eller XML-format. Eftersom syftet med arbetet som skagenomföras är att underlätta ett företags underhållning och utveckling av hemsidor, i det härfallet ett intranät, har JSON från början ett försprång eftersom formatet stöds av JavaScript igrunden [19]. JavaScript kan, exempelvis, bearbeta JSON till och från JavaScript-objekt ochvice versa utan att datan behöver tolkas av externa bibliotek. Eftersom 94 % av alla hemsidoranvänder JavaScript [20] och SysPartners intranät inte är ett undantag så är därför JSON igrunden ett mycket bra val av metod.

Vidare visar en publikation från 2009 att JSON presterar bättre än XML med avseende på hursnabbt bearbetningen av datan färdigställs [12]. Denna slutsats fattades utifrån resultaten aven serie tester där man jämförde JSON och XML. Det visar sig att JSON presterar bättre änXML i båda fallen. Denna slutsats styrks även av J. Einarsson och J. Winger-Lang som menaratt JSON är det snabbaste valet oavsett objektens storlek, där avkodning av JSON-objektsker upp till en faktor av 100 gånger snabbare än XML-motsvarigheten [6]. De menar ocksåatt JSON är det överlägsna valet när programmeringsspråket är Python eller JavaScript, därPython bearbetar JSON-objekt mellan 2,8 till 5,8 gånger snabbare än XML-motsvarigheten[6]. Det ligger också till fördel för JSON eftersom de ramverk som kommer att användas ärutvecklade i Python.

7

4 Metod

I det här kapitlet presenteras metoderna som används för att genomföra arbetet och besvararapportens frågeställning.

4.1 Analys

Syftet med API:et är att i slutändan erbjuda tillgång till samtlig data som utgör SysPartnersaktuella intranät. Genom att studera den kod som utgör SysPartners intranät, databas ochdiskussion med relevanta anställda så fastställs en generell bild av den funktionalitet somAPI:et förväntas erbjuda. En specifikation framställs där de resurser som API:et förväntadeskunna tillhandahålla specificeras, vilken URI som identifierar dem, samt vilka operationerklienten tillåts applicera på sina förfrågningar. Kravspecifikationen specificerar även hurolika typer av anställda ska hanteras där högre uppsatta behöver tillgång till mer informa-tion än övriga.

SysPartners aktuella intranät drivs inte isolerat av Drupal, utan är beroende av SysPartnersactive directory (AD) för användarhantering, rättighetshantering och filtrering av information.Således behövs en metod för att kommunicera med SysPartners AD via Django. SysPartneranvänder även VISMA för tidsrapporteringar och intranätet erbjuder funktionalitet för attse sin och sina anställdas tidsrapporteringar direkt via intranätet. Informationen hämtarintranätet från en lokalt underhållen Microsoft SQL-databas (MSSQL) som synkroniserasmed VISMA:s databas regelbundet. Således krävs också ett sätt för Django att kommuniceramed en MSSQL-server för att kunna bearbeta och visa tidsrapporteringar via API:et. Sys-Partners hårdvarubudget, som är en bonus anställda får att köpa utrustning för, kräver ocksåintegration med SysPartners AD för att anställdas hårdvarubudgetar ska kunna identifieras.

Användarhantering

Active Directory

SysPartners AD kommer att användas för två ändamål: autentisering och databearbetning.Autentisering mot AD är således klientens enda möjliga metod att autentisera sig för att låsaupp de olika nivåerna av data som API:et tillhandahåller. Vidare krävs ytterligare funktion-

8

4.1. Analys

alitet som möjliggör för API:et att avläsa information från SysPartners AD om användare, an-vändargrupper, information om användare, m.m. För ändamålen kommer django-auth-ldap[3] och django-ldapdb [5] att användas.

Tidsmodulen

Den typ av data som SysPartner vill erbjuda i intranätet finns inte hos VISMA, utan måsteframställas av API:et. Denna data visar bland annat hur många timmar de anställda harrapporterat in som är fakturerbara av SysPartner, och hur mycket respektive lite de behöverarbeta under resterande månad för att ligga på 100 % arbetstid. Med hjälp av AD:t behöverklientens eventuella underanställda identifieras och returneras i API:ets svar. Detta för attge chefer och gruppchefer en överblick över inte bara sin egen, utan även sina anställdasprestationer.

Microsoft SQL

SysPartners lokala MSSQL-server kommer att användas för att hämta tidsdata som deanställda har registrerat via VISMA. Det krävs därför funktionalitet som möjliggör för Djangoatt interagera med en MSSQL-server på ett smidigt och pålitligt sätt. När väl funktionalitetfinns som kan hämta information från databasen kommer Django att utföra själva bearbetnin-gen av datan. För kommunikationen mellan Django och MSSQL-servern kommer verktygetpyodbc [15] att användas. Pyodbc kräver i sin tur att det finns mjukvara och drivrutiner påservern som konfigurerats för SysPartners MSSQL-server.

Hårdvarubudget

Hårdvarubudgeten är en bonus som SysPartner delar ut till sina anställda varje månad ochår där de anställda får extra pengar att köpa hårdvara för. Summan som tilldelas är beroendeav flera olika faktorer, däribland den anställdes inrapporterade timmar för aktuell månad.En gång i månaden ska ett skript köras som itererar samtliga anställdas hårdvarubudgetoch utifrån dessa faktorer tilldelar en bonus. Precis som i tidsmodulen kommer AD:t attanvändas för att identifiera vilka anställda som den förfrågande klienten behöver ha tillgångtill. Vidare krävs funktionalitet som tillåter högsta chefer att modifiera hårdvarubudgeten föratt kunna bokföra budgetens kassaflöde och introducera nyanställda. Endast klienter somAD:t rapporterar som chefer kommer tillåtas att applicera metoder som DELETE, PUT ochPOST på API:ets resurser.

Databas

Som databasmotor kommer MySQL att användas [11]. Databasschemat är uppdelat i tre:hårdvarubas, bonus och historik. För varje ändring i en anställds budget måste ändringensparas i historiken, och för varje månad när en bonus tilldelas måste den sparas i bonusta-bellen. Varje år genomförs en uträkning som adderar samtliga bonusar en anställd tilldelatsunder året med en viss summa (årlig bonus) och som sedan ska sparas i hårdvarubasen somlägger grunden för nästa års budgetunderlag.

Utvecklingsmiljö

För att understödja projektets struktur kommer Git att användas för att bokföra arbetetsutveckling och möjliggöra för smidig versionshantering av koden. Vidare kommer ären-dehanteringssystemet Jira att användas för att planera arbetets fortskridande och ge enöverblick över implementerad och icke-implementerad funktionalitet.

9

4.2. Design

4.2 Design

Utifrån de krav som API:et förväntas erbjuda och hur de olika modulerna representerades iDrupals databas framställs en övergripande plan över hur API:et ska utformas. Här specifi-ceras hur modulerna samarbetar, hur informationen ska representeras i databasen, hur API:etska använda sig av SysPartners AD för användarhantering, hur tidsmodulen ska imple-menteras för att kommunicera med SysPartners MSSQL-server samt hur hårdvarubudgetenska utformas.

Databas

Det aktuella intranätet är som tidigare nämnt utvecklat i Drupal och använder MySQL somdatabasmotor. Efter diskussion med företaget bestämdes det att MySQL skulle användasför att lagra information åt API:et eftersom det var en bekant och populär motor som intelämnade några anledningar att byta. Databasschemat implementeras i en ny MySQL-databasoch ett skript utvecklas med syftet att enkelt kunna återställa databasen till ett visst tillstånd.Datan som skriptet ska återställa till hämtas från en aktuell databaskopia för att kunnajämföra databasen med Drupals databas efter ändringar och beräkningar. Skriptet utvecklasmed syfte att underlätta testandet av API:ets funktionalitet utan att manuellt behöva backadatabasen under arbetets gång.

Eftersom hårdvarubudgeten är den enda information som kommer lagras i databasen ärschemat mycket enkelt. Nedan visas det schema som kommer att resultera i databasta-beller. Djangos egna tabeller som används för bland annat sessionshantering och cache harutlämnats.

Figure 4.1: Databasdiagram över hårdvarubudgeten.

API

API:et kommer att delas upp i tre moduler: time_handler (tidshantering), budget_handler (bud-gethantering) och ldap_handler (användarhantering). Samtliga moduler kommer kommer attsepareras ifrån varandra med syftet att göra dem modulära. Varje modul har i sin tur sinaegna hjälpfunktioner, view-funktioner, models, m.m. Gemensamt för alla moduler är att de ärberoende av användarhantering, och därför kommer samtliga att nyttja ldap_handler för attidentifiera klienten och dennes eventuella underanställda.

Nedan följer en beskrivning över de resurser som API:et erbjuder, hur de identifieras,

10

4.3. Representationsmetod

vilka metoder som klienten kan applicera och vad API:et förväntas svara. Tillåtna metoderoch filtrering av API:ets svar bearbetas utifrån klientens identiferade företagsposition.

AnvändarmodulenResurs URI Metoder Beskrivning

Användare /users/ GET Listar aktiva användarefrån AD.

Användare /users/ăuidą GETReturnerar enskild an-vändare identifierad avuid.

Tidsmodulen

Tidsdata /time/ GET Listar all beräknad tids-data.

Tidsdata /time/ăstartą/ăendą/ GETListar all beräknad tids-data inom angivet datu-mintervall.

Budgetmodulen

Budgetbas /budgetbase/ GET, POST Listar samtliga anställdasbudgetbaser.

Budgetbas /budgetbase/ăuidą/ GET, PUT,DELETE

Listar enskild anställdsbudgetbas.

Budgetbonus /budgetbonus/ GET, POST Listar samtliga budget-bonusar.

Budgetbonus /budgetbonus/ăuidą/ GET, PUT,DELETE

Listar enskild användaresbudgetbonusar.

Budgethistorik /budgethistory/ GET, POST Listar samtlig budgethis-torik.

Budgethistorik /budgethistory/ăuidąGET, PUT,DELETE

Listar enskild användaresbudgethistorik.

Figure 4.2: Tabell över API:ets resurser.

4.3 Representationsmetod

Kvantitativ studie

För att komplettera litteraturstudien i teorikapitlet kommer en kvantitativ studie genomförassom utöver klienttester även studerar hur servern (API:et) påverkas av de två represen-tationsmetoderna. En mycket enkel hemsida kommer utvecklas som från API:et hämtardata som sedan bearbetas. Stresstestet aktiverar en klocka, skickar 300 förfrågningar tillAPI:et, och mottar sedan successivt API:ets svar som bearbetas till JSON-objekt eller XML-objekt beroende på vilket test som körs. När testet har bearbetat samtliga svar från servernstannar klockan. För ändamålet kommer JavaScript-funktionerna JSON.parse och DOM-Parser().parseFromString() användas för att avkoda svaren till JSON respektive XML.

Parallellt med testerna som körs på klientsidan så ska även, på serversidan, minnesåtgång,CPU-användning och tiden det tar från att servern mottar klientens förfrågan till att ett svarreturneras, att loggas. Till detta används verktyget psutil [14] där funktionen virtual_memory()används för att avläsa minnesåtgång och cpu_percent() används för att ge en decimalsiffrasom representerar systemets CPU-användning. Av dessa kommer medelvärdena beräknasoch ställas i relation till vilken representationsmetod som användes och hur lång tid det togför klienttesterna att färdigställas.

Testet kommer utformas i två scenarion, där det första går ut på att bearbeta små mängder

11

4.3. Representationsmetod

data och det andra scenariot går ut på att bearbeta stora mängder data. Datan som API:etreturnerar är faktiskt data som används av intranätet, med den enda skillnaden att för destora mängderna data kommer samma data duplicerats 255 gånger.

12

5 Implementation

Nedan beskrivs hur arbetet, med metoden som utgångspunkt, implementerats.

API

Det första steget i utformningen av API:et var att implementera grundläggande funktion-alitet enligt kravspecifikationen. Denna grundläggande funktionalitet består av in- och ut-loggning samt kallande på de funktioner som hämtar och modifierar API:ets resurser (hård-varubudget, tidsrapportering och användare). Under utvecklingen representerades all datasom JSON, för att senare kompletteras med XML för att kunna besvara rapportens frågeställ-ning.

Användarhantering

För autentiseringen mot SysPartners AD användes modulen django-auth-ldap. Django kon-figurerades till att använda modulen för autentisering vilket möjliggjorde för att användaDjangos inbyggda autentiseringsverktyg i resterande delar av API:et. Den enda skillnadenvar att användarens inloggningsuppgifter slogs upp mot SysPartners AD istället för enserverspecifik databas. Utöver autentisering användes också django-ldapdb för att hämtainformation från SysPartners AD som inte hade med autentisering att göra. I det här falletanvändes modulen endast för att hämta användare och information om varje användare.Django-ldapdb är en modul som samspelar med Django Models, vilket gör django-ldapdb tillett ORM för AD-servrar.

Ingen data sparas på SysPartners AD via API:et, och för att förhindra oavsiktligt sparandeanvändes en användare med enbart läsrättigheter. Information om användarna användesenbart för att bedöma deras olika rättigheter och för att binda samman den data som API:ethanterar med en specifik användare. En modell framtogs som hämtade nödvändig infor-mation från AD:t och representerade det som en objektinstans istället för rå text. Data somrepresenterades var bland annat användarens för- och efternamn, användarnamn, grup-pchef, kontaktuppgifter och unika ID (objectGUID).

Nedan visas en bild på API:ets svar när användarresursen begärs.

13

Figure 5.1: Lista över användare från API:et.

Tidshantering

API:et erbjöd tidsinformation om samtliga användare som bygger på en serie beräkningarsom sker på information hämtat från den lokala MSSQL-servern. Även här var aldrig avsik-ten att spara data på databasen eftersom tidsrapporteringen sker via VISMA, och intranätetssyfte var istället att räkna på de anställdas rapporteringar och erbjuda en överblick på sinegen och sina anställdas situation. Eftersom tidsrapporteringarna är många och MSSQL-databasen stor så utformades API:et till att utföra beräkningarna på en lokalt sparad cachesom uppdateras var 15:e minut. Detta gav en drastisk ökning i effektivitet eftersom det skerett stort antal uppslagningar särskilt för högre uppsatta anställda som behöver kunna sesamtliga anställdas rapporteringar. För att kommunicera med SysPartners MSSQL-serveranvänds pyodbc som konfigurerades till att ansluta sig mot SysPartners MSSQL-server. Py-odbc är en modul som agerar brygga mellan en MSSQL-server och Django, vilket även härmöjliggör för API:et att betrakta databasens innehåll som Django Models och den funktion-alitet som Django Models erbjuder.

När en klient anropade API:ets tidsmodul följde en serie beräkningar på tidsdata koppladetill klienten och dennes anställda. De slutgiltiga räknevärdena presenteras för användarenmed syftet att antingen läsas direkt eller via ett grafiskt gränssnitt som tolkar värdena och pre-senterar dem för klienten på ett mer intuitivt sätt. Eftersom tidsmodulens logik är beroendeav korrekt implementerad datumfunktionalitet användes ett öppet API för att hämta dagar

14

för varje månad och information om respektive dag (röd dag, arbetsdag, veckodag, m.m).Information därifrån användes för att beräkna de faktorer som slutligen resulterade i deräknevärden som API:et presenterar för klienten.

Nedan visas en bild på API:ets svar när tidsresursen begärs.

Figure 5.2: Ett utdrag ur API:ets tidsberäkning.

Budgethantering

Budgetmodulen utvecklades med stort fokus på vilken data klienten har tillgång till ochatt alla ändringar genomförs korrekt. För att göra detta så genomfördes alla nödvändigaberäkningar och kontroller före någon data sparades permanent i databasen. Detta innebaratt samtliga ändringar i databasen genomfördes och kontrollerades, för att sedan skrivas tilldatabasen i ett enda steg. På så sätt undviker API:et problem där en ändring har sparats iexempelvis budgetbasen medan inlägget i budgethistoriken inte kunde sparas. Innan infor-mationen slutligen sparades i databasen genomförs också en sundhetskontroll (sanity-check)på datan som bekräftar att det som Django tänker skriva till databasen stämmer överensmed det förväntade resultatet. Dessa säkerhetsmetoder implementerades med syftet attsäkerställa budgetens legitimitet. Eftersom budgeten hanterar anställdas rätt till pengar ärdet av stor vikt att all data som tas emot och returneras är korrekt, filtrerad och säker.

Nedan visas en bild på API:ets svar när budgetbasen begärs.

15

Figure 5.3: Ett utdrag ur API:ets hårdvarubudget.

Testning

För att säkerställa API:ets funktionalitet utvecklades tester i takt med att API:ets funktion-alitet utökades. För ändamålet användes Djangos testramverk som tillät tester att exekverapå en temporär databas som skapas, fylls och förstörs varje gång testerna skapas. Testernaverifierar att användare kan logga in och komma åt de resurser de tillåts göra, och att deförhindras tillgång till övriga resurser. Testerna verifierar också att hårdvarubudgeten, somär den enda funktionalitet där data modifieras, uppdateras korrekt och att de ändringar somgjorts stämmer överens med förväntat slutresultat.

Säkerhet

Före de sista stegen som handlar om att öppna intranätet för omvärlden behövdes en delsäkerhet beaktas. Djangos inbyggda hjälpfunktion check deploy 1 användes för att understödja

1https://docs.djangoproject.com/en/1.11/howto/deployment/checklist/

16

5.1. Front-end

sökandet efter eventuella säkerhetsbrister i API:et. Django konfigurerades till att inaktiveradebugging, för att inte obehöriga skulle få ta del av felmeddelanden; inaktivera överförin-gen av Cross-Site Request Forgery (CSRF)-kakor och sessionskakor över okrypterad HTTP,omdirigering till HTTPS för alla anslutningar, aktivering av Djangos inbyggda skydd motCross site scripting (XSS)-attacker och ett förbud aktiverades som förhindrar alla klienter frånatt hämta data som visas i en HTML frame-tagg. Vidare konfigurerades en Apache webserverpå en av SysPartners servrar till att servera Django-projektet bakom en krypterad HTTPS-anslutning och även här omdirigera osäker trafik till HTTPS-motsvarigheten.

5.1 Front-end

Tillsammans med SysPartner bestämdes det att arbetet i mån av tid även skulle innefattautvecklingen av ett front-end till intranätet för att i praktiken använda API:et och kunnamotivera eventuella förändringar. Eftersom front-end hamnar utanför ramarna för vadrapporten avser undersöka lämnas detta avsnitt kortfattat. Hemsidan utvecklades i ReactJStillsammans med Bootstrap och körs parallellt i samma Django-instans som API:et. Varjemodul i API:et representeras av en egen ReactJS-modul i intranätet som hämtar data frånAPI:et och presenterar det för användaren. Trots att intranätet och API:et körs på sammaserver under samma Django-instans så hålls de alltså isolerade från varandra för att möjlig-göra för intranätet att kunna underhållas och köras separat från API:et. Alla datafiltreringaroch säkerhetsbedömningar sköts av API:et för att inte exponera känslig data ty intranätetskod blir publik i samband med att den hämtas på klientens maskin.

Nedan visas en bild på gränssnittets tidsmodul.

Figure 5.4: Intranätets vy av tidsrapportering.

5.2 Representationsmetod

De mycket enkla klienttesterna utvecklades och API:et konfigurerades till att stödja bådeJSON och XML. Ett flertal tester exekverades för att verifiera att API och klient fungerar somförväntat innan de riktiga testerna kördes. För att mata klienten med data valdes API:ets listaöver användare som datamängd, där datan duplicerats 255 gånger för det första scenariot.

17

5.2. Representationsmetod

Nedan visar två tabeller storleken på de datamängder som användes för testerna, ochvilken testmiljö som användes. Som kan skådas är skillnaderna i filstorlek mellan JSON- ochXML-formaterad data mycket liten och för arbetets syfte oväsentlig.

Scenario 1 (stor datamängd)Format Filstorlek (bytes) Filstorlek (MiB)JSON 13 149 843 12.541XML 13 035 105 12.431

Scenario 2 (liten datamängd)Format Filstorlek (bytes) Filstorlek (MiB)JSON 51 572 0.0491XML 51 134 0.0488

Figure 5.5: Tabell över filstorlekarna som används av testerna.

TestmiljöOperativsystem Fedora 25 (64-bit)Webbläsare Google Chrome v58 (64-bit)Processor Intel Core i7 4700HQ 2,4 GHzMinne 12 GB DDR3 1600 MHz

Figure 5.6: Specifikation av den testmiljö som testerna exekverats på.

18

6 Resultat

Nedan följer de testdata som givits av de tester som presenterats i metodkapitlet. Eftersomklienten behöver vänta på att API:et ska returnera ett svar så ger resultatet även en generellbild över hur API:et presterar. Denna generella bild kompletteras dock med resultaten frånservern (API:et).

6.1 Scenario 1 - Stora datamängder

Tester där 300 st API-förfrågningar har begärts och besvarats för stora mängder data.

KlientTyp Total tid (sek) Total tid (min)JSON 476.2 7.9XML 1 081.5 18.0

Figure 6.1: Resultat av klientens tester för scenario 1.

19

6.2. Scenario 2 - Små datamängder

Scenario 1

200

400

600

800

1,000

1,200

Tid

(sek

)

JSON XML

Figure 6.2: Stapeldiagram över klienttesternas resultat för scenario 1.

Server (API)JSON XML

Medeltid per förfrågan (sek) 5.44 5.96CPU medelvärde 14.2 16.2CPU maxvärde 44.8 39CPU minimivärde 4.3 3.9Minnesanvändning medelvärde (%) 59.3 68Minnesanvändning maxvärde (%) 63.8 74.8Minnesanvändning minimivärde (%) 54.9 58.4

Figure 6.3: Resultat av serverns (API:ets) bearbetning av förfrågningarna för scenario 1.

6.2 Scenario 2 - Små datamängder

Tester där 300 st API-förfrågningar har begärts och besvarats för små mängder data.

KlientTyp Total tid (sek) Total tid (min)JSON 25.7 0.43XML 27.6 0.46

Figure 6.4: Resultat av klientens tester för scenario 2.

20

6.2. Scenario 2 - Små datamängder

Scenario 20

10

20

30

Tid

(sek

)

JSON XML

Figure 6.5: Stapeldiagram över klienttesternas resultat för scenario 2.

Server (API)JSON XML

Medeltid per förfrågan (sek) 0.14 0.16CPU medelvärde 13.8 13CPU maxvärde 46.2 29CPU minimivärde 3.2 0.8Minnesanvändning medelvärde (%) 60.1 59.5Minnesanvändning maxvärde (%) 61 59.9Minnesanvändning minimivärde (%) 59.1 59.2

Figure 6.6: Resultat av serverns (API:ets) bearbetning av förfrågningarna för scenario 2.

21

7 Diskussion

7.1 Resultat

Resultaten visar hur API:et och klienten presterar när det kommer till att bearbeta data rep-resenterat i JSON och XML för två olika datamängder. De givna resultaten banar slutligenväg för att besvara arbetets frågeställning: "Vilken av representationsmetoderna JSON och XMLger bäst prestanda för ett API och en klient med avseende på bearbetningstid och resursförbrukning?".

Klient

Scenario 1 - Stora datamängder

Testresultaten visar att klienten bearbetar stora JSON-datamängder 128 % mer effektivt änför stora XML-datamängder där den totala tiden var 7.9 minuter respektive 18 minuter.

Scenario 2 - Små datamängder

För klientens bearbetning av små datamängder visar sig resultaten vara förhållandevislikvärdiga. Bearbetningen av den mottagna JSON-datan sker 7 % mer effektivt än XML-motsvarigheten. Mätt i sekunder är skillnaden bara 1.9 sekunder där JSON-datan bearbe-tas på 25.7 sekunder och XML-datan bearbetas på 27.6 sekunder. För små datamängder ärsåledes tidsskillnaden försumbar för icke-tidskritiska applikationer även om JSON:s snab-bare bearbetningstid inte är att förglömma.

Slutsats - Klient

Resultaten menar att klientens JavaScript bearbetar stor och liten JSON-data mer effektivtän XML-motsvarigheten, med en tidsbesparing på 128 % respektive 7 %. Således kan enadelen av frågeställningen besvaras genom konstaterandet att JSON ger bäst prestanda medavseende på bearbetningstid för JavaScript-klienter. Detta förefaller rimligt när man beaktaratt JavaScript erbjuder inbyggd funktionalitet för att bearbeta JSON med JSON.parse(), somnämnt i metodkapitlet. XML å andra sidan kräver att datan tas emot för att sedan helt itererasgenom och till sist få sin data extraherad och lagrad i variabler, vilket är en mer krävandeuppgift.

22

7.1. Resultat

Server (API)

Scenario 1 - Stora datamängder

API:ets testresultat visar att bearbetningen av JSON respektive XML-data är förhållandevislikvärdiga, även om XML-bearbetningen förbrukade en större andel systemresurser. Medelti-den det tog för varje mottagen förfrågan att förberedas och slutligen returneras var 5.44sekunder för JSON-testet och 5.96 sekunder för XML-testet där JSON-förfrågningarna alltsåbearbetates 9.6 % snabbare. Den decimalsiffra som representerar CPU-användningen lan-dade på ett medelvärde på 14.2 för JSON-testet och 16.2 för XML-testet. Samma trend visas imedelanvändningen av systemets minne där systemet under JSON-testet förbrukade 59.3 %av systemets virtuella minne medan XML-testet förbrukade 68 %. En mer drastisk skillnadi medeltid per förfrågan förväntades i och med att metodens litteraturstudie tydde på störreöverlägsenhet för Pythons bearbetning av JSON-data. Det skall dock beaktas att den slutsat-sen fattades av stresstestandet av ett litet Pythonprogram som endast bearbetade JSON- ochXML-data, medan API:et använt för denna rapport istället bestod av ett helt ramverk. Förfat-tarna själva skriver att "De simpla program vi skrivit i JavaScript och Python är gjorda så att de skautföra så lite onödigt arbete som möjligt." [6], och medan API:et inte heller avser utföra onödigauppgifter så är det ett mer komplext system där mycket funktionalitet är involverat i bearbet-ningen av den data som slutligen returneras. En annan bidragande faktor är att Pythonpro-grammet i ovan nämnd studie bearbetar rådata till- och från JSON respektive XML, medanAPI:et enbart renderar samma data till JSON eller XML.

Scenario 2 - Små datamängder

Även för små datamängder visade sig API:et ha en lägre medeltid per förfrågan där JSON-testet gav en medeltid på 0.14 sekunder medan XML-testet istället hamnade på 0.16 sekun-der; en skillnad på 14 %. Mätt i sekunder är dock skillnaden mycket liten, och för API:etssyfte försumbar. När istället förbrukade systemresurser studeras så visas en mindre fördelför XML-testet. CPU-användningen för JSON-testet resulterade i ett medelvärde på 13.8 re-spektive 13 för XML-testet. CPU-användningen hade också ett betydligt högre maxvärde förJSON-testet jämfört med XML-testet, där värdet resulterade i 46.2 respektive 29. Skillnadeni de två testernas maxvärde låg till JSON:s nackdel även för stora datamängder i scenario 1,om än inte lika drastisk. Vidare visar det sig att systemet under JSON-testet förbrukade 1.5procentenhet mer virtuellt minne än XML-motsvarigheten.

Slutsats - API

Testresultaten visar att API:et presterar bäst i JSON-testen för både stora och smådatamängder med avseende på bearbetningstid. Vad gäller förbrukade systemresurser vardock resultaten varierande där stora datamängder resulterade i att XML-förfrågningarna för-brukade mer resurser när man beräknade dess medelvärden. För små datamängder för-brukade istället JSON-förfrågningarna mest systemresurser, även om skillnaderna är små.Med resultaten som utgångspunkt besvaras frågeställningen där JSON för både små ochstora datamängder gav bäst bearbetningstid per förfrågan. Vad gäller resursförbrukningpresterade JSON-testet för stora datamängder bättre än XML, medan XML-testet presterandemarginellt bättre än JSON för små datamängder.

Slutsats

Testresultaten visar att datamängder i JSON-format gav bäst resultat i både bearbetningstidoch systemförbrukning för både stora och små datamängder, bortsett från det fall där XMLhade marginellt lägre medelresursförbrukning för små datamängder. Det skall dock inteförglömmas att i det fall då XML-formatet gav minst resursförbrukning var medeltiden perförfrågan fortfarande lägre för JSON-formatet, och skillnaden i resursförbrukning var endast

23

7.2. Method

marginell. Utifrån testresultaten och den diskussion som förts i samband med dessa kon-stateras det slutligen att svaret på arbetets frågeställning, Vilken av representationsmetodernaJSON och XML ger bäst prestanda för ett API och en klient med avseende på bearbetningstid ochresursförbrukning?, är JSON.

Det bör dock inte förglömmas att testresultaterna inte berättar om dataformatens påverkanpå systemet efter att klienten har tagit emot och koverterat datan till interna objekt. Detkan alltså finnas faktorer som påverkar de båda dataformatens effektivitet när datan skaanvändas för framställning av ny data eller datan ska valideras. Till exempel så erbjuderXML-formatet ett verktyg, XML Schema, som kan användas för att validera datans struktur.Detta arbete har istället fokuserats på de båda dataformatens påverkan på klient och systemfrån att datan framställs tills att den tagits emot och är redo att behandlas ytterligare hosklienten.

7.2 Method

API

Arbetet med att utveckla det API som skulle lägga grund för den kommande kvantitativastudien hindrades flera gånger av ett behov att refaktorera små och stora delar av kodbasen.Eftersom erfarenheten av såväl ramverket Django som språket Python båda var tämligensmå upplevdes det i samband med att programmet växte ett större behov av att göra om, görarätt. Det är svårt att göra om arbetet utifrån samma situation som innan och förvänta sigett annorlunda resultat, men om uppgiften istället skulle tilldelas mig idag när erfarenhetenfinns hade jag från början lagt ner mer tid på att planera hur kod skulle struktureras och hurmoduler skulle samarbeta. Alternativet är att, som gjorts nu, skriva kod som refaktorerasnär bättre lösningar identifieras, men det är knappast en effektiv lösning. Å andra sidan såär jag väldigt nöjd med slutresultatet, och det som hade kunnat erhållits av bättre planeringär effektivitet snarare än annorlunda kodbas.

I efterhand identifieras dock två områden som hade förbättrat både aktuell kodbas ocharbetets effektivitet. Det första handlar om sessionshantering, där Django erbjuder mycketkompetent funktionalitet för att hålla reda på vilken klient det är som anropar API:et. Nären klient anropar API:et så finns bland annat användarens användarnamn lagrat i det bi-fogade sessionsobjektet som view-funktionerna tar emot. En bättre lösning hade varit attfrån början överlagra autentiseringsmodulen som sparar denna data i sessionsobjektet vidautentisering mot SysPartners AD, och istället lagra användarens ID (ObjectGUID). Detta pågrund av att ID:t används för att identifiera användare i hela API:et, från att begära speci-fika resurser från API:et till att internt identifiera användarens tillhörande hårdvarubudget,VISMA-användare, m.m. Som det ser ut nu så sker en hel del uppslagningar mot AD:t där ettanvändarobjekt får hämtas identifierat av det användarnamn som erhålls av det förfrågandesessionsobjektet. Detta sker såväl som i varje view-funktion som i flera av hjälpfunktionerna.Att därför direkt ha möjlighet att hämta en användare från AD:t utan att först behöva hittadennes ID hade därför underlättat en hel del vad gäller både kodstruktur och effektivitet.En ännu bättre lösning hade varit att direkt vid autentisering hämta relevant användarob-jekt från AD:t som sedan refereras till i sessionsobjektet. Det gör förvisso systemet mindreskalbart, men i dagens användningsområde för API:et är det bekymret irrelevant.

Det andra bekymret handlar om VISMA:s databas och de många hämtningar av dess data.SysPartner har en lokal kopia på databasen som man använder internt för bland annat detäldre intranätet och det som utvecklats under detta arbete. Den här databasen är dock väldigtlångsam, vilket resulterade i att för anställda som i tidsmodulen har tillgång till flera anställ-das tidsrapporteringar blev väntetiden olidlig. För anställda som ska kunna se samtliga

24

7.3. Studie

tidsrapporter blev databasförfrågningarna många och väntetiden var mellan 30 sekunderoch en minut. För att lösa det problemet valde jag att spara en hel del data som cache. Detgjorde API:et mycket snabbare, men det är fortfarande obekvämt att tvingas underhållafunktionalitet som vid ett visst tidsintervall sparar all denna data i en lokal databas. Efteratt den lösningen implementerats fick också en hel del kod skrivas om då uppslagningarnanu skulle göras mot den sparade kopian, som bara var stora textsträngar, snarare än motVISMA:s databas. Det är heller inte en skalbar lösning eftersom datan som sparas vid enviss tidpunkt kan bli alldeles för stor. En bättre lösning hade varit att utveckla funktionalitetsom hämtar all relevant data från VISMA:s databas som krävs för att bearbeta flera anställdapå en gång utan att behöva hämta specifik data för varje användare som itereras igenom.Att bara behöva skicka en förfrågan hade alltså löst behovet av cache eftersom flaskhalsen isituationen var mellan API och VISMA:s databas.

REST

Arbetets utgångspunkt var att det utvecklade API:et skulle följa de principer som REST in-nebär. Det visar sig att det slutgiltiga API:et till mångt och mycket lever upp till de principersom Roy Fielding myntade i sin avhandling [7]. API:et är tillståndslöst och fattar inga beslutsom påverkas av vilket tillstånd klienten befinner sig i, bortsett från vilken anställningsformsom den inloggade klienten har. Varje tillgänglig resurs identifieras med en unik URI somklienten kan applicera olika HTTP-metoder på beroende på vad klienten vill åstadkomma.För att ytterligare filtrera data kan klienten bifoga parametrar i sin förfrågan, och använderklienten API:et fel svaras denne med en representativ felkod och ett felmeddelande innehål-landes orsak till att dennes begäran inte kunde bearbetas. För att göra API:et användbartmen samtidigt intuitivt har också ett användargränssnitt utvecklats som är skilt från API:et.Användargränssnittets syfte är enbart att kommunicera med API:et, och utifrån API:ets svarhjälpa användaren navigera informationen.

7.3 Studie

Eftersom den data som användes i testerna bestod av intern, möjligtvis känslig, data frånSysPartner finns den inte tillgänglig som bilaga. Detta innebär att studiens replikerbarhetblir lidande, även om studien istället har kompletterats med storleken på den data somtesterna använde sig av. Eftersom API:et ej heller existerar som varken bilaga eller öppenkällkod så är det i praktiken omöjligt att på ett helt korrekt sätt replikera den server somtesterna anropar, även om API:ets moduler har beskrivits i metodkapitlet. Däremot så harde funktioner som testerna använder sig av för att bearbeta mottagen data och rapporteraresursförbrukning klarlagts vilket innebär att samma tester kommer kunna utföras fast påannan data och med en annorlunda server.

Vad gäller serverns pålitlighet så kan även resultatet påverkas av en egenimplementeradserver eftersom den funktionalitet som till slut returnerar data från servern, som nämnt, inteär tillgänglig. Det bör dock nämnas att det är samma funktionalitet som använts för bådeJSON- och XML-testerna bortsett från att renderingsmotorn är annorlunda för de två olikarepresentationsmetoderna. Således bör man kunna dra slutsatsen att resultaten blir propor-tionerliga även för en egenimplementerad server. Detta på grund av att den funktionalitetsom förbereder datan inte har något med JSON eller XML att göra.

Validitetshot

Biblioteken som används för att bearbeta data och ange resursförbrukning är väl beprövadeoch koden är öppen, och den data de rapporterar får för syftet därför bedömas som tro-värdiga. Däremot så har bara klienttesterna exekverats i Google Chrome. Enligt hemsi-

25

7.4. Källkritik

dan DigitalTrends hamnade Google Chrome v55, två versioner äldre en den som använtsi testerna, på andraplats i den del som stresstestar JavaScript med verktyget Kraken JavaScriptv1.1 efter webbläsaren Vivaldi [1]. Google Chrome är alltså ett fullgott alternativ när det kom-mer till att stresstesta JavaScript, även om ytterligare webbläsare i testerna hade stärkt dessvaliditet. Vidare är Djangos utvecklingsserver (vilken användes i testerna) konfigurerad attbearbeta sex förfrågningar i taget. Det betyder att av de 300 förfrågningar som klienttesternaskickade till servern så bearbetades bara sex av dem i taget. Om ändringar görs i konfig-urationen eller om en annan server med annan konfiguration används för att driva API:etkommer därför resultatet se annorlunda ut. Om exempelvis alla förfrågningar bearbetas sam-tidigt kommer det ta väldigt lång tid för den sista att färdigställas, och servern kommer ocksåförbruka mer systemresurser eftersom den kommer att arbeta med ett annat antal uppgifterparallellt.

7.4 Källkritik

Några av de källor som hänvisats till i arbetet kommer från artiklar och bloggar. I de fall dettaförekommer är det dock främst med syfte att motivera eller stärka en viss utgångspunkt,som exempelvis den blogg som presenterade ett diagram över REST-arkitekturens framfart[9]. Ansträngningar har dock gjorts för att i de fall hemsidor hänvisats till i rapporten hittainformation som hemsidan i sin tur har angivit som källa, men dessa ansträngningar har intealltid lyckats. I vissa fall är hemsidorna i referenslistan hänvisade till projekts egen dokumen-tation, som får bedömas som de mest trovärdiga källorna när det kommer till hur projektetska användas och vad det erbjuder. I övrigt så har stora ansträngningar gjorts för att hittarelevant och aktuell information, och flera publikationer har förkastats på grund av sin åldertill förmån för en nyare informationskälla. Detta gäller även publikationer som aldrig ellerbara några enstaka gånger citerats, om en mer trovärdig ersättare har kunnat finnas. För depublikationer med fler citeringar har å andra sidan citeringarna granskats för att skapa enuppfattning om i vilka sammanhang publikationen har blivit citerad i, och om orsaken tillcitat har varit i positiv eller negativ bemärkelse.

26

8 Slutsats

Syftet med rapporten var att undersöka vilka representationsmetoder som presterade bästi ett API och en klient med avseende på den tid det tar att bearbeta datan och vilka sys-temresurser som går åt. För syftet valdes typerna JSON och XML. Eftersom syftet medarbetet också var att kunna fatta en slutsats som är anknuten till SysPartner och deras behovutvecklades ett komplett intranät att bedriva testerna på, snarare än ett simpelt API-skelett.Resultaten visar att JSON presterar bäst på både server- och klientsida för både stora ochsmå datamängder, bortsett från att XML förbrukade marginellt mindre systemresurser påserversidan för små datamängder. JSON-motsvarigheten hade dock hade en lägre medeltidper förfrågan för samma scenario. Syftet med rapporten har således uppfyllts ty arbetets lär-domar har diskuterats och frågeställningen, vilken av representationsmetoderna JSON och XMLger bäst prestanda för ett API och en klient med avseende på bearbetningstid och resursförbrukning?,har besvarats: JSON-formaterad data resulterade alltid i snabbare bearbetningstid än XML-motsvarigheten. JSON-formaterad data förbrukar också mindre systemresurser, förutom närdatamängderna är små då medelförbrukningen av systemresurserna var marginellt högre änXML-motsvarigheten.

Arbetets resultat har möjlighet att användas som underlag för framtida val av representa-tionsmetod av både företag, privatpersoner och forskare. Eftersom resultaten beskriver hurrepresentationsmetoderna har påverkat såväl bearbetningstid som resursanvändning finnsmöjlighet att beakta och prioritera utifrån de konsekvenserna som representationsmetodernainnebär. Till exempel kan resultaten användas för att avgöra olika representationsmetoderför tidskritiska applikationer eller resurskritiska applikationer.

8.1 Framtida arbete

Intressant framtida arbete är att mer noggrant studera JSON och XML:s påverkan på sys-temet som helhet med fler mätvärden. Detta skulle kunna innebära att man i större utsträck-ning testar flera delar av API:et i ett isolerat system som inte påverkas av de externa faktorersom detta arbetets tester gjorts. Testerna i detta arbete har utförts på en personlig dator,och ansträngningar har gjorts för att de olika testerna ska kunna göras med samma förut-sättningar. Det är dock inte jämförbart med ett minimalt, kontrollerat och isolerat systemsom möjliggör för testerna att bättre mäta resursförbrukning och tidseffektivitet. Ett sådant

27

8.1. Framtida arbete

system skulle också bana väg för mer trovärdiga avläsningar av andra faktorer som nätverk-strafik, buffrar, köbildning i processorn, m.m. Det skulle också möjliggöra för att kunna sep-arera klient- och servertesterna eftersom de skulle kunna köras helt separat på olika fysiskaeller virtuella maskiner.

28

Bibliography

[1] Battle of the browsers: Edge vs. Chrome vs. Firefox vs. Opera vs. Vivaldi. URL: https://www.digitaltrends.com/computing/best-browser-internet-explorer-vs-chrome-vs-firefox-vs-safari-vs-edge/ (visited on 05/15/2017).

[2] Django. URL: https://www.djangoproject.com/ (visited on 03/01/2017).

[3] Django Authentication Using LDAP. URL: https://pythonhosted.org/django-auth-ldap/ (visited on 05/15/2017).

[4] Django REST Framework. URL: http://www.django- rest- framework.org/(visited on 03/01/2017).

[5] Django-ldapdb. URL: https://github.com/django-ldapdb/django-ldapdb(visited on 05/15/2017).

[6] Joel Einarsson and Johannes Winger-Lang. “En jämförande prestandastudie mellanJSON och XML”. B.S. Thesis. Blekinge Institute of Technology, Department of SoftwareEngineering, 2014, p. 54.

[7] Roy Thomas Fielding. “Architectural styles and the design of network-based softwarearchitectures”. PhD thesis. University of California, Irvine, 2000.

[8] ICT Facts and Figures 2016. URL: https://www.itu.int/en/ITU-D/Statistics/Documents/facts/ICTFactsFigures2016.pdf (visited on 03/01/2017).

[9] Guy Levin. The Rise of REST API. URL: http://blog.restcase.com/the-rise-of-rest-api/ (visited on 03/01/2017).

[10] B. Lin, Y. Chen, X. Chen, and Y. Yu. “Comparison between JSON and XML in Applica-tions Based on AJAX”. In: 2012 International Conference on Computer Science and ServiceSystem. Aug. 2012, pp. 1174–1177. DOI: 10.1109/CSSS.2012.297.

[11] MySQL. URL: https://www.mysql.com/ (visited on 06/09/2017).

[12] Nurseitov Nurzhan, Paulson Michael, Reynolds All, and Izurieta Clemente. “IzurietaC: Comparison of JSON and XML Data Interchange Formats: A Case Study. Scenario2009.” In: (2014).

[13] Cesare Pautasso. “RESTful Web Services: Principles, Patterns, Emerging Technologies”.In: Web Services Foundations. Ed. by Athman Bouguettaya, Quan Z. Sheng, and FlorianDaniel. New York, NY: Springer New York, 2014, pp. 31–51. ISBN: 978-1-4614-7518-7.DOI: 10.1007/978-1-4614-7518-7_2.

29

Bibliography

[14] Psutil. URL: https://pythonhosted.org/psutil/ (visited on 05/15/2017).

[15] Pyodbc. URL: https : / / github . com / mkleehammer / pyodbc (visited on05/15/2017).

[16] Fielding R., Gettys J., Gettys Internet-draft J., Frystyk H., Berners-lee T., Mogul Mit/lcsjC., Dech J. Gettys, Mogul J. C., and Bernerslee T. “Hypertext Transfer Protocol -HTTP/1.1.” In: (2009).

[17] Guido Schmutz, Daniel Liebhart, and Peter Welkenbach. Service-oriented Architecture:An Integration Blueprint: a Real-world SOA Strategy for the Integration of HeterogeneousEnterprise Systems: Successfully Implement Your Own Enterprise Integration ArchitectureUsing the Trivadis Integration Architecture Blueprint. Packt Publishing Ltd, 2010.

[18] Security in Django. URL: https://docs.djangoproject.com/en/1.11/topics/security/ (visited on 05/15/2017).

[19] W3schools - JSON. URL: https://www.w3schools.com/js/js_json_intro.asp(visited on 03/01/2017).

[20] W3techs. URL: https : / / w3techs . com / technologies / details / cp -javascript/all/all (visited on 03/01/2017).

[21] L. Xiao-Hong. “Research and Development of Web of Things System Based on RestArchitecture”. In: 2014 Fifth International Conference on Intelligent Systems Design and En-gineering Applications. June 2014, pp. 744–747. DOI: 10.1109/ISDEA.2014.169.

30