diff --git a/media/Server/Onderzoeksverslag.pdf b/media/Server/Onderzoeksverslag.pdf new file mode 100755 index 0000000..90282a7 Binary files /dev/null and b/media/Server/Onderzoeksverslag.pdf differ diff --git a/media/Server/eindverslag persoonlijke bijdrage/.editorconfig b/media/Server/eindverslag persoonlijke bijdrage/.editorconfig old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.gitattributes b/media/Server/eindverslag persoonlijke bijdrage/.gitattributes old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/CODEOWNERS b/media/Server/eindverslag persoonlijke bijdrage/.github/CODEOWNERS old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/CODE_OF_CONDUCT.md b/media/Server/eindverslag persoonlijke bijdrage/.github/CODE_OF_CONDUCT.md old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/COMMIT_CONVENTION.md b/media/Server/eindverslag persoonlijke bijdrage/.github/COMMIT_CONVENTION.md old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/CONTRIBUTING.md b/media/Server/eindverslag persoonlijke bijdrage/.github/CONTRIBUTING.md old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/FUNDING.yml b/media/Server/eindverslag persoonlijke bijdrage/.github/FUNDING.yml old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/ISSUE_TEMPLATE/bug_report.yml b/media/Server/eindverslag persoonlijke bijdrage/.github/ISSUE_TEMPLATE/bug_report.yml old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/ISSUE_TEMPLATE/config.yml b/media/Server/eindverslag persoonlijke bijdrage/.github/ISSUE_TEMPLATE/config.yml old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/ISSUE_TEMPLATE/feature_request.yml b/media/Server/eindverslag persoonlijke bijdrage/.github/ISSUE_TEMPLATE/feature_request.yml old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/PULL_REQUEST_TEMPLATE.md b/media/Server/eindverslag persoonlijke bijdrage/.github/PULL_REQUEST_TEMPLATE.md old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/auto_assign.yml b/media/Server/eindverslag persoonlijke bijdrage/.github/auto_assign.yml old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.github/labels.yml b/media/Server/eindverslag persoonlijke bijdrage/.github/labels.yml old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/.gitignore b/media/Server/eindverslag persoonlijke bijdrage/.gitignore old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/LICENSE b/media/Server/eindverslag persoonlijke bijdrage/LICENSE old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/LICENSES/.gitkeep b/media/Server/eindverslag persoonlijke bijdrage/LICENSES/.gitkeep old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/README.md b/media/Server/eindverslag persoonlijke bijdrage/README.md old mode 100644 new mode 100755 diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/img/uml.jpg b/media/Server/eindverslag persoonlijke bijdrage/src/img/uml.jpg new file mode 100755 index 0000000..a72e2c5 Binary files /dev/null and b/media/Server/eindverslag persoonlijke bijdrage/src/img/uml.jpg differ diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/main.tex b/media/Server/eindverslag persoonlijke bijdrage/src/main.tex old mode 100644 new mode 100755 index c4490d9..1bb0993 --- a/media/Server/eindverslag persoonlijke bijdrage/src/main.tex +++ b/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} diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/references.bib b/media/Server/eindverslag persoonlijke bijdrage/src/references.bib old mode 100644 new mode 100755 index 8b13789..0d5dac3 --- a/media/Server/eindverslag persoonlijke bijdrage/src/references.bib +++ b/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 = { + &lt;p&gt;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.&lt;/p&gt; + } +} +@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} +} diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/sections/1 inleiding.tex b/media/Server/eindverslag persoonlijke bijdrage/src/sections/1 inleiding.tex new file mode 100755 index 0000000..02c9849 --- /dev/null +++ b/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. diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/sections/1 introduction.tex b/media/Server/eindverslag persoonlijke bijdrage/src/sections/1 introduction.tex deleted file mode 100644 index 744d0e4..0000000 --- a/media/Server/eindverslag persoonlijke bijdrage/src/sections/1 introduction.tex +++ /dev/null @@ -1,6 +0,0 @@ -\newpage - -\section{Introduction} -\label{sec:introduction} - - diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/sections/2 data serialisatie.tex b/media/Server/eindverslag persoonlijke bijdrage/src/sections/2 data serialisatie.tex deleted file mode 100644 index be9e0b2..0000000 --- a/media/Server/eindverslag persoonlijke bijdrage/src/sections/2 data serialisatie.tex +++ /dev/null @@ -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 - diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/sections/2 probleemstelling.tex b/media/Server/eindverslag persoonlijke bijdrage/src/sections/2 probleemstelling.tex new file mode 100755 index 0000000..96ab763 --- /dev/null +++ b/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. diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/sections/3 theoretisch.tex b/media/Server/eindverslag persoonlijke bijdrage/src/sections/3 theoretisch.tex new file mode 100755 index 0000000..30515b6 --- /dev/null +++ b/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} diff --git a/media/Server/eindverslag persoonlijke bijdrage/src/sections/4 conclusie.tex b/media/Server/eindverslag persoonlijke bijdrage/src/sections/4 conclusie.tex new file mode 100755 index 0000000..ab5dbca --- /dev/null +++ b/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}