feat: Work on research paper

media/Server/eindverslag persoonlijke bijdrage/src/main.tex

@@ -1,15 +1,8 @@
-\documentclass[10pt]{article}
+\documentclass[conference]{IEEEtran}
 
-%/ Use case: margins
-\usepackage[letterpaper,
-  top=2cm,
-  bottom=2cm,
-  left=2cm,
-  right=2cm,
-  marginparwidth=1.75cm]{geometry}
 %/ Use case: language and spell checking
 \usepackage[utf8]{inputenc}
-\usepackage[english]{babel}
+\usepackage[dutch]{babel}
 %/ Use case: uppercase headers
 \usepackage{titlecaps}
 \usepackage{sectsty}
@@ -29,31 +22,54 @@
 \usepackage{pgfplots}
 \usepackage{pgfplotstable}
 
+\graphicspath{ {./img/} }
+
 \pgfplotsset{compat=1.18}
 
 \allsectionsfont{\mdseries\scshape}
 
-\title{\titlecap{\scshape Title}}\normalfont
-\author{Wessel Tip $<$contact@wessel.gg$>$ (Student number 696770, \url{https://wessel.gg/})}
-\date{Computer Engineering at InHolland University of Applied Sciences\linebreak Year 2, Semester 2 (Jan. 2024 - Jun. 2024)}
+\title{\titlecap{\scshape Vergelijking van API architecturen voor de API Server van het Project Robotica}}\normalfont
+\author{\IEEEauthorblockN{Wessel Tip $<$contact@wessel.gg$>$ (Student nummer 696770, \url{https://wessel.gg/})}
+\IEEEauthorblockA{
+Technische Informatica --- Project Robotica \\
+Hoogeschool Inholland Alkmaar \\
+ Jaar 2, Semester 2 (Jan. 2024 - Jun. 2024)
+}}
 
 \begin{document}
 
 \maketitle
 
 \begin{abstract}
-In dit verslag zal de ontwikkeling van mijn persoonlijke bijdrage aan het project
-Robotica worden besproken. Mijn persoonlijke bijdrage zal de communicatie tussen
-de gebruiker, de robot en een aparte dataserver beheren.
+In dit verslag zal besproken worden waarom er is gekozen om een RESTful API
+te maken voor het project Robotica.
 
-Het hele project zal in Csharp worden geschreven door zijn objectgeoriënteerde aard.
+De toegankelijkheid en schaalbaarheid van de API-architecturen REST, SOAP,
+GraphQL en gRPC zullen worden vergeleken om uiteindelijk op de conclusie te
+komen waarom REST gebruikt word.
 \end{abstract}
 
 \tableofcontents
 
-\input{sections/1 introduction}
+\input{sections/1 inleiding}
+\input{sections/2 probleemstelling.tex}
+\input{sections/3 theoretisch.tex}
+\input{sections/4 conclusie.tex}
 
+
+\section*{Erkenningen}
+\label{sec:erkenningen}
+De auteur wilt graag de volgende mensen bedanken voor hun contributie bij het schrijven van dit verslag:
+\begin{itemize}
+  \item[] \makebox[3.2cm]{\textbf{Buurman, W. J.}\hfill} Groepsgenoot
+  \item[] \makebox[3.2cm]{\textbf{Slikker, T.}\hfill} Groepsgenoot
+  \item[] \makebox[3.2cm]{\textbf{Ottens, N.}\hfill} Begeleiding
+  \item[] \makebox[3.2cm]{\textbf{Tilmann, K.}\hfill} Begeleiding
+\end{itemize}
+
+\label{sec:referenties}
 \bibliographystyle{IEEEtran}
-\bibliography{references.bib}
+\bibliography{references}
+% \nocite{*}
 
 \end{document}

media/Server/eindverslag persoonlijke bijdrage/src/references.bib

@@ -1 +1,109 @@
-
+@book{masse2011,
+  title        = {
+    REST API design rulebook designing consistent restful web service
+    interfaces mark massee. ed.: Simon St. Laurent
+  },
+  author       = {Massee, Mark},
+  year         = {2011},
+  publisher    = {OReilly},
+  url          = {
+    https://books.google.nl/books?id=eABpzyTcJNIC&lpg=PR3&ots=vBPD3-ldKC&dq=restful%20api&lr&hl=nl&pg=PP1#v=onepage&q=restful%20api&f=false
+  },
+  note         = {Geraadpleegd op Juni 8, 2024},
+  place        = {Beijing}
+}
+@article{Śliwa_Pańczyk_2021,
+  title        = {
+    Performance comparison of programming interfaces on the example of REST
+    API, GraphQL and gRPC
+  },
+  author       = {Śliwa, Mariusz and Pańczyk, Beata},
+  year         = {2021},
+  month        = {Dec.},
+  journal      = {Journal of Computer Sciences Institute},
+  volume       = {21},
+  doi          = {10.35784/jcsi.2744},
+  url          = {https://ph.pollub.pl/index.php/jcsi/article/view/2744},
+  note         = {Geraadpleegd op Juni 10, 2024},
+  abstractnote = {
+    <p>The article presents a comparison of the performance of
+    three ways of implementing programming interfaces used in web applications
+    - REST, GraphQL and gRPC. For the purposes of the research, three
+    applications were developed, which were made in each of the indicated
+    technologies and with the same functionalities. The applications were used
+    for performance tests carried out with the use of the k6 tool. The
+    applications are used to measure the execution time, performance and volume
+    of processed data during display and adding operations. The obtained
+    results allowed for the conclusion that the best interface in terms of
+    performance (measured as the number of transactions per second) and server
+    response time is REST. However, in terms of the smallest data volume, gRPC
+    is the best choice.</p>
+  }
+}
+@misc{Souza_2012,
+  title        = {Evaluating application programming interfaces as communication artefacts},
+  author       = {
+    Afonso, Luiz Marquez and F. de G. Cerqueira, Renato and de Souza, Clarisse
+    Sieckenius
+  },
+  year         = {2012},
+  url          = {http://www3.serg.inf.puc-rio.br/docs/MarquesPPIG2012.pdf},
+  note         = {Geraadpleegd op Juni 6, 2024}
+}
+@misc{facebook,
+  title        = {GraphQL: A query language for your API},
+  author       = {Facebook},
+  url          = {https://graphql.org},
+  note         = {Geraadpleegd op Juni 14, 2024}
+}
+@misc{w3c,
+  title        = {SOAP Version 1.2 Part 1: Messaging Framework Second Edition},
+  author       = {World Wide Web Consortium W3C},
+  url          = {https://www.w3.org/TR/soap12-part1/},
+  note         = {Geraadpleegd op Juni 15, 2024}
+}
+@misc{google,
+  title        = {gRPC - A high-performance, open source universal RPC framework},
+  author       = {Google},
+  url          = {https://grpc.io/},
+  note         = {Geraadpleegd op Juni 16, 2024}
+}
+@inproceedings{Hartig,
+  title        = {Semantics and Complexity of GraphQL},
+  author       = {Hartig, Olaf and Perez, Jorge},
+  year         = {2018},
+  booktitle    = {Proceedings of the 2018 World Wide Web Conference},
+  location     = {Lyon, France},
+  publisher    = {International World Wide Web Conferences Steering Committee},
+  address      = {Republic and Canton of Geneva, CHE},
+  series       = {WWW '18},
+  pages        = {1155–1164},
+  doi          = {10.1145/3178876.3186014},
+  isbn         = {9781450356398},
+  url          = {https://doi.org/10.1145/3178876.3186014},
+  note         = {Geraadpleegd op Juni 12, 2024},
+  abstract     = {
+    GraphQL is a recently proposed, and increasingly adopted, conceptual
+    framework for providing a new type of data access interface on the Web. The
+    framework includes a new graph query language whose semantics has been
+    specified informally only. This has prevented the formal study of the main
+    properties of the language. We embark on the formalization and study of
+    GraphQL. To this end, we first formalize the semantics of GraphQL queries
+    based on a labeled-graph data model. Thereafter, we analyze the language
+    and show that it admits really efficient evaluation methods. In particular,
+    we prove that the complexity of the GraphQL evaluation problem is
+    NL-complete. Moreover, we show that the enumeration problem can be solved
+    with constant delay. This implies that a server can answer a GraphQL query
+    and send the response byte-by-byte while spending just a constant amount of
+    time between every byte sent. Despite these positive results, we prove that
+    the size of a GraphQL response might be prohibitively large for an internet
+    scenario. We present experiments showing that current practical
+    implementations suffer from this issue. We provide a solution to cope with
+    this problem by showing that the total size of a GraphQL response can be
+    computed in polynomial time. Our results on polynomial-time size
+    computation plus the constant-delay enumeration can help developers to
+    provide more robust GraphQL interfaces on the Web.
+  },
+  numpages     = {10},
+  keywords     = {web queries, query language, JSON, GraphQL}
+}

media/Server/eindverslag persoonlijke bijdrage/src/sections/1 inleiding.tex

@@ -0,0 +1,16 @@
+
+\section{Inleiding}
+\label{sec:inleiding}
+
+In de moderne softwareontwikkeling spelen API's (Application Programming Interfaces)
+een belangrijke rol. Ze vormen de brug tussen verschillende softwarecomponenten
+en zorgen voor een gestructureerde manier om gegevens uit te wisselen.\cite{masse2011}
+
+In het Robotica-project, waarbij voor mijn persoonlijke bijdrage de communicatie
+tussen de gebruiker en de robot centraal staat,
+is de keuze van een geschikte API-architectuur van groot belang.
+
+De API moet eenvoudig te implementeren en te onderhouden zijn.
+Dit verslag zal vier verschillende API architecturen bespreken en vergelijken
+om uiteindelijk tot de conclusie te komen voor welk architectuur het beste is
+voor het project.

media/Server/eindverslag persoonlijke bijdrage/src/sections/1 introduction.tex

@@ -1,6 +0,0 @@
-\newpage
-
-\section{Introduction}
-\label{sec:introduction}
-
-

media/Server/eindverslag persoonlijke bijdrage/src/sections/2 data serialisatie.tex

@@ -1,11 +0,0 @@
-Er zijn vele opties om data te verzenden tussen client en server.
-Voor dit project is er voor gekozen om data te serialiseren naar JSON.
-Dit is een veelgebruikte methode om data te verzenden tussen client en server.
-Het voordeel van JSON is dat het een lichtgewicht formaat is en dat het makkelijk te lezen is.
-Dit is handig voor debugging en het is makkelijk om te zetten naar een object in JavaScript.
-Een nadeel van JSON is dat het niet binair is en dat het niet zo snel is als binair.
-Dit is echter geen probleem voor dit project, omdat de hoeveelheid data die verstuurd wordt klein is.
-\subsection{Serialisatie}
-\label{sec:serialisatie}
-% Path: 2 data serialisatie.tex
-

media/Server/eindverslag persoonlijke bijdrage/src/sections/2 probleemstelling.tex

@@ -0,0 +1,31 @@
+\section{Probleemstelling}
+\label{sec: Probleemstelling}
+
+In het project is het belangrijk dat de gebruiker op afstand can communiceren
+met de mapping robot. De robot moet de commando's van de gebruiker kunnen
+ontvangen en uitvoeren.
+
+De gebruiker moet ook kunnen zien wat de robot allemaal gemapt heeft, om
+eventueel in te grijpen als dit niet klopt.
+
+De robot vereist een structuele manier om deze gegevens uit te wisselen, en
+de optie om meerdere robots tegelijkertijd te besturen. De aandachtspunten
+hiervoor zijn:
+
+\subsection{Toegankelijkheid van de diverse functies}
+Het interface dat de gebruiker ziet moet alle verzamelde data laten zien.
+Hij zal de mapping en de geplande route moeten presenteren in een overzichtelijke
+manier. Ook moet de robot diverse commando's vanuit de gebruiker kunnen ontvangen
+om zo de gewenste taken uit te kunnen voeren.
+
+\subsection{Schaalbaarheid en Prestaties}
+Naarmate het project groeit, moeten de communicatie kanalen tussen de verschillende
+componenten schaalbaar blijven zonder dat dit ten koste gaat van de prestaties.
+Dit betekent dat de gekozen API-oplossing in staat moet zijn om een toenemend aantal
+verzoeken af te handelen zonder vertragingen of systeemuitval.
+
+\subsection{Onderhoudbaarheid en Uitbreidbaarheid}
+De gekozen API-architectuur moet eenvoudig te onderhouden zijn, met een heldere
+en overzichtelijke structuur. De architectuur moet ook felxiebel genoeg zijn
+om toevoegingen en aanpassingen te ondersteunen zonder dat het codebase herschreven
+moet worden.

media/Server/eindverslag persoonlijke bijdrage/src/sections/3 theoretisch.tex

@@ -0,0 +1,127 @@
+\section{theoretisch Kader}
+\label{sec:theoretisch kader}
+
+\subsection{API-Architecturen}
+API's (Application Programming Interfaces) zijn onmisbare componenten in moderne
+software. Deze API's maken de communicatie tussen verschillende
+softwarecomponenten mogelijk.\cite{Souza_2012}
+
+Er zijn over de jaren vele verschillende manieren bedacht voor het ontwerpen
+en implementeren van API's, elk met zijn eigen voordelen en nadelen.
+\cite{Śliwa_Pańczyk_2021}
+
+Dit hoofdstuk zal vier van de meest gebruikte API architecturen bespreken.
+
+\subsection{RESTful (Representational State Transfer)}
+\label{ssec:rest}
+REST is een architectuur dat wordt gebruikt voor het communiceren van gegevens
+om netwerkapplicaties te ontwerpen.
+
+Het maakt gebruik van standaard HTTP-methoden (zoals GET, POST, PUT, DELETE)
+om gegevens te communiceren tussen clients en servers.\cite{masse2011}
+
+Door de simpiliciteit en het al gebruik maken van de bestaande HTTP protocollen
+is REST een populaire keuze voor API's. Dit maakt het ook erg geschikt voor
+web gebaseerde applicaties.
+
+\subsubsection{Voordelen van REST}
+\label{sssec:voordelen en nadelen van rest}
+\begin{enumerate}
+  \item \textbf{Eenvoudige structuur} --- gebaseerd op standaard HTTP-methoden
+   en JSON
+  \item \textbf{Makkelijke implementatie} --- meeste talen ondersteunen de basis
+   van webrequests en JSON serialisatie al
+  \item \textbf{Schaalbaarheid} --- RESTful API's zijn stateless en kunnen
+   eenvoudig horizontaal geschaald worden, echter zal de prestatie wel minder
+   zijn dan andere methodes zoals gRPC of GraphQL.\cite{Śliwa_Pańczyk_2021}
+\end{enumerate}
+
+\subsubsection{Nadelen van REST}
+Echter heeft REST ook zijn nadelen, sommige hiervan zijn:
+\begin{enumerate}
+  \item \textbf{Overbodig veel data} --- Minder geschikt voor complexere query's
+   en datastructuren (over-fetching en under-fetching)
+  \item \textbf{Documentatie} --- Geen directe ondersteuning voor documentatie,
+   schemas en typecontrole
+  \item \textbf{Real-time} --- Doordat de connectie niet levend wordt gehouden nadat
+   de aanvrag is afgehandeld is het minder geschikt voor real-time communicatie.
+\end{enumerate}
+
+\subsection{SOAP (Simple Object Access Protocol)}
+SOAP is een protocol voor uitwisseling van informatie netzoals REST vermeld in
+\autoref{ssec:rest}. Echter is SOAP meer complex en minder populair dan REST.
+
+SOAP maakt gebruik van XML voor het sturen van berichten en ondersteunt
+in tegenstelling tot REST verschillende transportprotocollen zoals
+HTTP en SMTP. SOAP biedt ook robuuste beveiligings- en transactiebeheerfuncties
+wat REST niet zo maar heeft.\cite{Śliwa_Pańczyk_2021,w3c}
+
+\subsubsection{Voordelen van SOAP}
+\begin{enumerate}
+    \item \textbf{Beveiliging} --- Sterke beveiligingsfuncties met behulp van
+    WS-Security en ondersteuning voor ACID transacties.
+\end{enumerate}
+
+\subsubsection{Nadelen van SOAP}
+Net zoals REST heeft SOAP ook zijn nadelen:
+\begin{enumerate}
+    \item \textbf{Ingewikkeld formaat} --- Complexiteit en overhead door XML-berichten
+    \item \textbf{Prestatieproblemen} --- Langzamere prestaties vergeleken met REST
+\end{enumerate}
+
+\subsection{GraphQL}
+GraphQL is een querytaal voor API's die is ontwikkeld door Facebook in 2012\cite{facebook}.
+In tegenstelling tot REST en SOAP, waarbij de server bepaalt welke gegevens
+worden geretourneerd, stelt GraphQL clients in staat om een specifieke set data
+op te vragen. Ook biedt GraphQL een sterke typecontrole en introspectie aan door
+middel van schemas.\cite{Hartig}
+
+\subsubsection{Voordelen van GraphQL}
+Voordelen van GraphQL:
+\begin{enumerate}
+    \item \textbf{Efficiëntie} --- Door de query aard van GraphQL is het
+     makkelijk om snel en flexibele bepaalde stukken data aan te vragen.
+    \item \textbf{Gegevensbesparing} --- Omdat de gebruiker alleen maar de
+     gegevens ontvangt die zij nodig hebben, vermindert dit over-fetching en
+     under-fetching waardoor er meer bandbreedte en rekenkracht wordt bespaard.\cite{Hartig}
+    \item \textbf{Documentatie} --- Sterke typecontrole en introspectie door het
+     gebruik van schemas.
+     \item \textbf{compatibiliteit} --- Ook al is het niet gewenst, GraphQL
+      is compatibiel met RESTful clients, hierdoor kan de implementatie vrij
+      simpel zijn als de kracht van GraphQL niet nodig is.
+\end{enumerate}
+
+\subsubsection{Nadelen van GraphQL}
+Nadelen van GraphQL:
+\begin{enumerate}
+    \item \textbf{Intergratie} --- Door de aard van GraphQL is de
+     serverimplementatie veel complexer, en daarom ook aangeraden om een library
+     te gebruiken.
+    \item \textbf{Complexiteit} --- Mogelijkheid van te complexe queries die
+     de serverbelasting verhogen
+\end{enumerate}
+
+\subsection{gRPC (Google Remote Procedure Call)}
+gRPC is een modern RPC-framework dat in 2016 door Google is ontwikkeld. Het maakt
+gebruik van HTTP/2 voor transport, Protocol Buffers voor berichtserialisatie en
+biedt functies zoals load balancing en monitoring. Door zijn load balancing
+functies is gRPC zeer geschikt voor high-performance en real-time communicatie.\cite{google,Śliwa_Pańczyk_2021}
+
+Echter is het wel de moeilijkste methoden om te implementeren en te onderhouden.
+
+\subsubsection{Voordelen van gRPC}
+\begin{enumerate}
+    \item \textbf{Prestatie} --- Hoge prestaties door het gebruik van protocol
+     buffers, berichten zijn tot 30\% kleiner dan JSON.
+    \item \textbf{Real-time} --- In tegenstelling tot REST, GraphQL en SOAP
+     is gRPC wel geschikt voor real-time communicatie
+\end{enumerate}
+
+\subsubsection{Nadelen van gRPC}
+\begin{enumerate}
+    \item \textbf{Complexiteit} --- Complexer dan alle andere methodes vermeld
+     om op te zetten en te debuggen
+     \item \textbf{Limitaties} --- Door het vele gebruik van HTTP/2.0 is het niet
+      compatibel met oudere web browsers. Ook is er veel minder bekend over gRPC
+      dan de andere methodes door zijn relatief nieuwe staat.
+\end{enumerate}

media/Server/eindverslag persoonlijke bijdrage/src/sections/4 conclusie.tex

@@ -0,0 +1,73 @@
+\section{Conclusie}
+\label{sec:conclusie}
+
+Na een evaluatie van de verschillende API architectuur vermeld in \autoref{sec:theoretisch kader}
+en de eisen van het Robotica-project, is er tot de conclusie gekomen dat REST
+de meest geschikte oplossing is.
+
+De uiteindelijke UML diagram voor de API server is te zien in \autoref{fig:uml}.
+
+\subsection{Overwegingen}
+\label{ssec:overwegingen}
+De belangrijkste punten die in overwegingen zijn genomen bij het kiezen van de
+API architectuur waren:
+
+\begin{enumerate}
+    \item \textbf{Te ontwikkelen zonder libraries} --- Een van de vereisten van
+     het project is dat de API server met zo min mogelijk libraries gemaakt moet
+     worden.
+    \item \textbf{Toegankelijkheid van de API} --- Het is essentieel dat de
+     API eenvoudig te begrijpen en te gebruiken is. De API moest alle verzamelde
+     data op een overzichtelijke manier kunnen presenteren.
+    \item \textbf{Onderhoudbaarheid en Uitbreidbaarheid}: De API moet eenvoudig
+    te onderhouden zijn, met een heldere en overzichtelijke structuur. Daarnaast
+    moest de architectuur flexibel genoeg zijn om toekomstige uitbreidingen en
+     aanpassingen te ondersteunen zonder dat de codebase herschreven moet worden.
+\end{enumerate}
+
+\subsection{Keuze voor REST}
+Na het overwegen van de bovenstaande eisen en de doelen van het Robotica project,
+is er uiteindelijk voor gekozen om REST te gebruiken door de volgende punten:
+
+\begin{enumerate}
+    \item \textbf{Eenvoudige implementatie} --- REST maakt gebruik van standaard
+     HTTP/1.1-methoden, waardoor het gemakkelijk te implementeren is zonder de
+     noodzaak van complexe frameworks of libraries. Hierdoor kan de API ontwikkeld
+     worden met alleen een `TcpListener`.
+    \item \textbf{Breed ondersteund en compatibel} --- Door zijn leeftijd
+     ondersteund Vrijwel iedere webbrowser de infrastructuur waar REST op
+     gebasseerd is, dit maakt het een ideale keuze voor toegankelijke
+     webgebaseerde applicaties.
+    \item \textbf{Flexibiliteit en uitbreidbaarheid} --- RESTful APIs kunnen
+     eenvoudig worden uitgebreid met nieuwe functionaliteiten zonder bestaande
+     endpoints te verstoren. Dit maakt het mogelijk om de API aan te passen aan
+     eventuele nieuwe functies van het project.
+\end{enumerate}
+
+\subsection{Afweging tegen alternatieven}
+\label{ssec:afweging tegen alternatieven}
+Hoewel de alternatieve architecturen ook voordelen bieden over REST,
+waren er enkele beperkingen die hen minder geschikt maakten voor dit project:
+
+\begin{enumerate}
+    \item \textbf{SOAP} --- Hoewel SOAP sterke beveiligingsfuncties biedt,
+     werd het als te complex beschouwd voor de behoeften van dit project.
+     De XML-gebaseerde berichten van SOAP introduceren heel wat overhead
+     waardoor er meer ruimte voor fouten is.
+    \item \textbf{GraphQL} --- Hoewel GraphQL veel flexibeler en efficiënter
+     data kan opvragen dan REST, wordt er bij dit project geen gebruik gemaakt
+     van grote set key-value paren, waardoor GraphQL overbodig is. Ook maakt de
+     complexiteit het moeilijk om GraphQL te implementeren zonder bestaande
+     library.
+    \item \textbf{gRPC} --- gRPC biedt hoge prestaties en real-time communicatie,
+     maar de complexiteit net zoals GraphQL en de beperkingen tot het gebruik
+     van nieuwere browsers maakten het minder geschikt voor dit project.
+\end{enumerate}
+
+\subsection{UML model voor de API Server}
+\label{ssec:uml model voor de api server}
+\begin{figure}[H]
+    \includegraphics[width=0.5\textwidth]{uml.jpg}
+    \caption{Resulterende UML voor de API server.}
+    \label{fig:uml}
+\end{figure}