This study aimed to examine transport layer API:s for the game development software Unity, and conclude its effect on latency. This effect was examined by conducting a controlled experiment, whereas three transport layer API:s, KCP, Telepathy, and Steamworks.NET were active on three different open-source Unity online games. The underlying network infrastructure Mirror was integrated to utilize each transport layer API, which also provided the components necessary to capture latency at runtime. In a second unstable connection experiment, the packet loss rate of 30% was configured to analyze the transport layer API:s performance during a poor connection. Although previous work has analyzed Mirror, the corresponding transport layer API within Mirror, and its effect on latency, have not been researched. The results suggest that Steamworks.NET achieves a significantly increased latency compared to KCP and Telepathy, though Telepathy only significantly increases from KCP under unstable network conditions.

This report explores of the feasibility of using pattern matching for implementing a robust Natural Language Interface (NLI) over a limited Application Programming Interface (API). Because APIs are used to such a great extent today and often in mobile applications, it becomes more important to find simple ways of making them accessible to end users. A very intuitive way to access information via an API is using natural language. Therefore, this study first explores the possibility of building a corpus of the most common phrases used for a particular API. It is then explored how those phrases adhere to patterns, and how these patterns can be used to extract meaning from a phrase. Finally it evaluates an implementation of an NLI using pattern matching system based on the patterns. The result of the building of the corpus shows that although the amount of unique phrases used with our API seems to increase quite steadily, the amount of patterns those phrases follow converges to a constant quickly. This implies that it is possible to use these patterns to create an NLI that is robust enough to query an API effectively. The evaluation of the pattern matching system indicates that this technique can be used to successfully extract information from a phrase if its pattern is known by the system. / Den här rapporten utforskar hur genomförbart det är att använda mönstermatchning för att implementera ett robust användargränssnitt för styrning med naturligt språk (Natural Language Interface, NLI) över en begränsad Application Programming Interface (API). Eftersom APIer används i stor utsträckning idag, ofta i mobila applikationer, har det blivit allt mer viktigt att hitta sätt att göra dem ännu mer tillgängliga för slutanvändare. Ett mycket intuitivt sätt att komma åt information är med hjälp av naturligt språk via en API. I den här rapporten redogörs först för möjligheten att bygga ett korpus för en viss API and att skapa mönster för mönstermatchning på det korpuset. Därefter utvärderas en implementation av ett NLI som bygger på mönstermatchning med hjälp av korpuset. Resultatet av korpusuppbyggnaden visar att trots att antalet unika fraser som används för vårt API ökar ganska stadigt, så konvergerar antalat mönster på de fraserna relativt snabbt mot en konstant. Detta antyder att det är mycket möjligt att använda desssa mönster för att skapa en NLI som är robust nog för en API. Utvärderingen av implementationen av mönstermatchingssystemet antyder att tekniken kan användas för att framgångsrikt extrahera information från fraser om mönstret frasen följer finns i systemet.

Transport Layer Security (TLS) is a secure communication protocol between a client and a server over a network. The TLS protocol provides the two endpoints with confidentiality through symmetric encryption, endpoint authentication using public-key cryptography, and data integrity using a MAC. However, studies show that security vulnerabilities within TLS connections are often caused by developers misusing TLS library APIs. We measure the usability of four TLS libraries by performing a developer user study. Participants were given code that connects to google.com through HTTP, and tasked with using a TLS library to change the code so that it connects securely to Google through HTTPS. Our results help show what makes a library usable and what problems arise for developers using these TLS libraries. We found that the main way to ensure a TLS library is usable is to focus on having clear documentation. From our results, we provide suggestions on how to create usable documentation.

Describes the creation of an e-commerce store consisting of a client application, a REST API and a database. In this e-commerce store, two APIs containing Klarna's and PayPal's payment solutions have been integrated. These have also been compared in a simpler literature study. An e-commerce store consisting of the three components ordered above has been created. Both payment solutions have been implemented in the store. Based on a literature study, it has been stated that PayPal's API is suitable for better complex applications where you want a lot of freedom to be able to tailor the functions. Klarnas API is better adapted for applications that can be developed fast and are user-friendly. / Beskriver skapandet av en e-handelsbutik bestående av en klientapplikation, ett REST API och en databas. I den här ehandelsbutiken har två API:er innehållande Klarnas och PayPals betallösningar integreras. Dessa har även jämförts i en enklare litteraturstudie. En e-handelsbutik som bestod av de tre komponenter som beskrevs ovan har skapats. Båda betallösningarna har implementerats i butiken. Utifrån en litteraturstudie och så har det konstaterats att PayPals API lämpar sig bättre åt komplexa applikationer där man vill ha mycket frihet över att kunna skräddarsy funktionerna. Klarnas API är bättre anpassat för applikationer som ska kunna utvecklas fort och vara användarvänliga

The Generic Security Service Application Program Interface (GSS-API) is an architecture that facilitates applications using distributed security services in a mechanism-independent fashion. GSS-API is supported by various underlying mechanisms and technologies such as Kerberos version 5 and public-key technologies. However, no one-time password based GSS-API mechanism existed. This thesis focuses on an investigation using one-time passwords together with RADIUS authentication as a protection facility for a GSS-API mechanism. This thesis presents a security architecture using one-time passwords to establish a GSS-API security context between two communicating peers. The proposed one-time password based GSS-API mechanism could be used to enhance the security of user authentication. Moreover, the mechanism can greatly facilitate static-password based system’s transition to stronger authentication. / IETF GSS-API är ett applikationsgränssnitt (API) som tillhandahåller distribuerade säkerhetstjänster för autentisering och datakonfidentialitet oberoende av den underliggande säkerhetarkitekturen. Applikationer som skrivs mot detta API kan på detta sätt flyttas eller porteras utan att västentligen skrivas om. GSS-API stöds av ett flertal undrliggande säkerhetsarkitekturer som tex Kerberos 5, Windows NTLM och PKI. API har också sk bindings för "C" och Java. I dagsläget finns det dock ingen lösning som baseras på engångslösenord. Denna magisteruppsats har som mål att undersöka möjligheten att använda engångslösenord tillsammans med RADIUS för att implementera en ny GSS-API mechanism. Denna uppsats presenterar ett förslag för hur RADIUS och engångslösenord kan användas för att säkra kommunikationen mellan två GSS-API entiteter. Den föreslagna mekanismen kan också användas för att förbättra säkerheten för användarautentisering och möjliggöra en övergång från statiska lösenord till stark autentisering.

Inom denna rapport så kommer det gås igenom vilka tekniker och metoder som har används för att skapa en implementation en ny sorts webbaserat API. Det nya API't heter GraphQL och upfyller samma syfte som det mer traditionella REST API som används mycket utav företag och organisationer i dagsläget. Det som skiljer GraphQL mot REST är att GraphQL använder sig av "Query Language" för att kommunicera med API't genom att hämta eller skicka information. Implementationen har utförts inom .NET Framework hos företaget Quicksearch. Utvecklingen har skett inom företagets datasystem och API't kan hämta information från deras databas och skicka det vidare till användaren. Verktygen som har använts för att skapa applikationen är utvecklingsprogrammet Visual Studio tillsammans med programmeringsspråket C\#. Programmet Postman har använts till hjälp för utveckling och testning av API't. Relevanta metoder för att skapa API't inkluderar bibliotek riktat mot GraphQL och sammankoppling mot databasen. Designmönster har varit viktiga i projektet och dessa är "Dependency Injection" och "Model-View-Controller" för att skapa en web applikation. Slutresultatet är ett GraphQL API som kan forma enkla förfrågningar riktat mot en data-modell eller objekt. Även en jämförelse av GraphQL mot REST API har utförts med resultatet att det finns distinkta skillnader mellan de två konceptenför men för att komma fram till en övergripandeslutsats över vilket API som är ett bättre alternativ så behövs ytterligare tester. / This report will walkthrough several techniques and methods that have been used to create a new kind of web-based API. This new kind of API is called GraphQL and fullfils the same purpose as the more traditionally used REST API. What differs between these two types of API is that GraphQL uses a ”Query Language” when the user communicates with the API. The implementation is done in .NET Framework together with a company named Quicksearch. The development has been done within Quicksearch’s computer system and the API can request information from the company’s database and send it back to the user of the API. The tools that have been used to develop the API are Visual Studio as the development enviroment, along with the programming language C#. Postman is a software that have also been used to help develop and test the GraphQL API. Relevant methods used in the development includes libraries directed to create a GraphQL API and libraries used to create the connection to the database. Design patterns have also be important in the development and the most noticeable ones have been ”Dependency Injection” and ”Model-View-Controller” to create the application. The end result is an API that is able to recieve simple queries directed against a simple data-model or object. Aditionally a comparison between GraphQL and REST have been done and the result is that there are distinct differences between the two types of API but there is a lack of scientific reasarch and knowledge to make the conclusion of which is the better alternative and additional tests are required.

The aim of this project has been to investigate whether the headless CMS Sanity can live up to the needs of the the train operator GoAhead Nordic for its website in the transition from EpiServer. To investigate this, the existing website has been recreated as closely as possible. A studio/user interface has been built from scratch in Sanity where schemes and structure has been set for what content an editor can and must enter. Thereafter the content is fetched through an API to a standalone web application. In the web application, React components have been created based on the fetched content from Sanity. The work has been performed in an agile project form and regular meetings were held with the customer to constantly keep relevant focus and priority. The result has shown that even though there are a few minor problems still present there is a great reliability that with a little more time they will be solved. The conclusion of this work is that the headless CMS Sanity lives up to the needs of the customer and that the interface is easy to handle and understand. GoAhead Nordic has been very pleased with what was shown at the demonstrations and has decided to use Sanity as its new CMS / Målet med detta arbete har varit att undersöka om det huvudlösa CMS:et Sanity kan leva upp till de behov järnvägsoperatören GoAhead Nordic har för sin webbplats i övergången från EpiServer. För att undersöka detta har den befintliga webbplatsen återskapats i så stor utsträckning som möjligt. En studio/ användargränssnitt har byggts upp från grunden i Sanity där scheman och struktur har satts upp för hur en redaktör kan och får mata in innehåll. Därefter har detta innehåll hämtats via ett API till en helt fristående webbapplikation. I webbapplikationen har React-komponenter skapats utifrån innehållet som hämtats från Sanity. Arbetet har utförts i en agil projektform och regelbundna möten har hållits med kunden för att hela tiden ha relevant fokus och prioritering. Resultatet har visat att det i dagsläget finns små problem som inte hunnit lösas inom ramen för detta projekt men att det finns en stor tillförlitlighet att de kommer gå att lösa med lite mer tid. Slutsatsen i detta arbete är att det huvudlösa CMS:et Sanity lever upp till de behov som kunden har och att gränssnittet är lätt att hantera och förstå. GoAhead Nordic har varit mycket nöjda med det som visats upp på de regelbundna demonstrationerna och har beslutat sig för att använda Sanity som sitt nya CMS.

In February 2018 the students Andreas Karlsson and Emil Franzén contacted Danfoss Power Solutions in Älmhult, shortly after they were offered to perform a thesis. A thesis about developing an SDK in the programming language C# for Danfoss Power Solutions newly developed API, PLUS+1 System API 2.0. As a part of the thesis a mini service tool was to be created to show the powers of the SDK and then evaluate the SDK by letting a company perform a usability test. By the end of May an SDK was delivered written in C# along with a mini service tool for use in demonstration. But because of time issues there were no usability test performed.

The dynamic query language GraphQL is gaining popularity within the field as more and more software architects choose it as their architectural model of choice when designing an API. The dynamic nature of the GraphQL queries provide a different way of thinking about data fetching, focusing more on the experience for the API consumer. The language provides many exciting features for the field, but not much is known about the implications of implementing them. This thesis analyzes the architecture of GraphQL and explores its attributes in order to understand the tradeoffs and performance implications of implementing a GraphQL architecture in a data-fetching API, as opposed to a conventional REST architecture. The results from the architectural analysis suggests that the GraphQL architecture values the usability and supportability attributes higher than its REST counterpart. A performance experiment was performed, testing the internal performance of GraphQL versus REST in a use-case where its dynamic functionality is not utilized (returning the same static response as its REST equivalent). The results indicate that the performance of GraphQL implementations are lower than that of its REST equivalents in use-cases where the dynamic functionality is not utilized.

The aim of this work is to design and develop mobile iOS application for portal Mojilidi - platform iPhone. Design and control of this app must be similar to android application. During application's development was used tool called Sketch to create design for the application. Swift version 4.2 was used to program application. For communication was used URLSession library to communicate with server. Application also is using technoglogies such as MapKit for location entry, MessageKit for chat or CoreData for local storage.