mirror of
https://github.com/Wessel/Roommapper.git
synced 2026-07-25 17:20:53 +02:00
fix: Fix verslag
This commit is contained in:
@@ -325,7 +325,7 @@ version: 3.1.0
|
||||
nodigheid om de code te herschrijven al wil ik het in Next.js doen heb ik
|
||||
besloten om voor dit project
|
||||
|
||||
** [XVI 06-06-2024] Updaten van de robot-side server code
|
||||
* [XVI 06-06-2024] Updaten van de robot-side server code
|
||||
Nu er een aantal bugs uit de servercode zijn gehaald zal ik de code op de
|
||||
robot nogmaals herschrijven maar nu met de nieuwe libraries. Ook zullen alle
|
||||
benodigde routes geimplementeert worden om de Server set af te maken.
|
||||
@@ -343,7 +343,19 @@ version: 3.1.0
|
||||
overgestapt op het gebruik van gebruiker invulbare namen. Dit maakt het veel
|
||||
makkelijker om een bepaalde map te laten zien.
|
||||
|
||||
* [XVII 15-06-2024] UML diagrammen bijgewerkt
|
||||
* [XVIII 24-06-2024] Pathfinding route toegevoegd aan API
|
||||
Nadat dfe compatibiliteit voor routeplanning toegevoegd was, is er ook een
|
||||
API endpoint voor geschreven:
|
||||
|
||||
** POST /api/v1/path/plan
|
||||
Deze route wordt gebruikt om een route te berekenen tussen twee punten.
|
||||
- De route wordt berekend door middel van een A* algoritme, dit is een
|
||||
algoritme die de kortste route tussen twee punten berekend.
|
||||
- De route wordt vervolgens opgeslagen in de database, en de route wordt
|
||||
teruggegeven aan de gebruiker.
|
||||
- Als input body neemt deze route een array met objecten.
|
||||
|
||||
* [XIX 15-06-2024] UML diagrammen bijgewerkt
|
||||
Nu de broncode van de Server compleet zijn heb ik de UML diagrammen
|
||||
bijgewerkt om overeen te komen met de broncode. Ook heb ik de desbetreffende
|
||||
modules bij elkaar gegroepeerd en de correcte lijntjes getrokken.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 409 KiB |
@@ -39,21 +39,23 @@ Hoogeschool Inholland Alkmaar \\
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{abstract}
|
||||
In dit verslag zal besproken worden waarom er is gekozen om een RESTful API
|
||||
te maken voor het project Robotica.
|
||||
% \begin{abstract}
|
||||
% In dit verslag zal besproken worden waarom er is gekozen om een RESTful API
|
||||
% te maken voor het project Robotica.
|
||||
|
||||
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}
|
||||
% 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
|
||||
|
||||
\newpage
|
||||
\input{sections/1 inleiding}
|
||||
\input{sections/2 probleemstelling.tex}
|
||||
\input{sections/3 theoretisch.tex}
|
||||
\input{sections/4 conclusie.tex}
|
||||
\input{sections/4 methode}
|
||||
\input{sections/5 resultaten}
|
||||
\input{sections/6 conclusie.tex}
|
||||
|
||||
|
||||
\section*{Erkenningen}
|
||||
@@ -62,8 +64,8 @@ De auteur wilt graag de volgende mensen bedanken voor hun contributie bij het sc
|
||||
\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
|
||||
\item[] \makebox[3.2cm]{\textbf{Ottens, N.}\hfill} Opdrachtgever
|
||||
\item[] \makebox[3.2cm]{\textbf{Tilmann, K.}\hfill} Opdrachtgever
|
||||
\end{itemize}
|
||||
|
||||
\label{sec:referenties}
|
||||
@@ -71,4 +73,6 @@ De auteur wilt graag de volgende mensen bedanken voor hun contributie bij het sc
|
||||
\bibliography{references}
|
||||
% \nocite{*}
|
||||
|
||||
\input{sections/7 bijlage.tex}
|
||||
|
||||
\end{document}
|
||||
|
||||
@@ -1,16 +1,20 @@
|
||||
|
||||
\section{Inleiding}
|
||||
\label{sec:inleiding}
|
||||
In de moderne tijd speelt automatisering een steeds grotere rol in het
|
||||
verbeteren van efficiëntie en het verlichten van huishoudelijke taken.
|
||||
|
||||
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}
|
||||
Een goed voorbeeld hiervan is het stofzuigen. Dit wordt in de moderne tijd
|
||||
steeds meer door autonome robots gedaan. Deze robots zijn ontworpen om zelfstandig
|
||||
schoon te maken en tijd te besparen. Om dit te kunnen doen moet de robot niet
|
||||
alleen de ruimte kunnen navigeren, maar ook objecten kunnen vermijden en de
|
||||
meest efficiënte schoonmaakroute kunnen plannen.
|
||||
|
||||
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.
|
||||
Om aan de eigenaar van desbetreffende robot controle te geven wordt er vaak gebruik
|
||||
gemaakt van knoppen op de robot zelf. Dit is echter niet altijd even handig, omdat
|
||||
de robot vaak onder meubels staat en de knoppen niet altijd even goed bereikbaar zijn.
|
||||
|
||||
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.
|
||||
Om dit te verhelpen dient er een controlepaneel (ookwel bekend als een
|
||||
\textit{Web Interface}) gemaakt te worden. Via deze interface
|
||||
zal de eigenaar de mogelijkheid krijgen om de robot op een afstand
|
||||
te bedienen en monitoren.
|
||||
|
||||
@@ -1,31 +1,70 @@
|
||||
\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.
|
||||
\subsection{Probleemanalyse}
|
||||
\label{ssec:probleemanalyse}
|
||||
|
||||
De gebruiker moet ook kunnen zien wat de robot allemaal gemapt heeft, om
|
||||
eventueel in te grijpen als dit niet klopt.
|
||||
API's (\textit{Application Programming Interfaces}) zijn onmisbare componenten in moderne
|
||||
software. Door middel van een API in combinatie met een set van afspraken
|
||||
(een \textit{protocol}) is het mogelijk meerdere softwarecomponenten met elkaar
|
||||
te integreren. Deze API's maken de communicatie tussen verschillende
|
||||
softwarecomponenten mogelijk.\cite{Souza_2012}
|
||||
|
||||
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:
|
||||
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} In dit onderzoek wordt er een vergelijking gesteld
|
||||
tussen vier verschillende API architecturen (REST, SOAP, GraphQL en gRPC)
|
||||
om te bepalen welke het meest geschikt is voor het project.
|
||||
|
||||
\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.
|
||||
Bij het kiezen van een API architectuur wordt er rekening gehouden met een bepaald
|
||||
aantal criteria. De API moet ontwikkelt worden zonder dat er externe libraries
|
||||
gebruikt worden. Dit betekent dat de API vanaf de grond af aan moet worden opgebouwd.
|
||||
|
||||
\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.
|
||||
De API moet ook in staat zijn om de communicatie tussen de verschillende componenten
|
||||
van de robot te ondersteunen. Dit betekent dat de API de communicatie tussen de
|
||||
gebruiker en de robot moet ondersteunen, en de communicatie tussen de verschillende
|
||||
robots onderling.
|
||||
|
||||
De interface die wordt gepresenteerd aan de eindgebruiker dient alle verzamelde
|
||||
data te 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{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
|
||||
om toevoegingen en aanpassingen te ondersteunen zonder dat de codebase herschreven
|
||||
moet worden.
|
||||
|
||||
De robot vereist een structuele manier om deze gegevens uit te wisselen, en
|
||||
de optie om meerdere robots tegelijkertijd te besturen.
|
||||
|
||||
Een bijkomende eis vanuit de opdrachtgever is dat de software van het beroepsproduct
|
||||
object-georieënteerd is.
|
||||
|
||||
\subsection{Vraagstelling}
|
||||
De hoofdvraag van dit onderzoek luidt:
|
||||
|
||||
\begin{quote}
|
||||
"\textit{Welke API architectuur is het beste geschikt voor de specifieke eisen
|
||||
van het project, waarbij de communicatie tussen verschillende
|
||||
softwarecomponenten, de ondersteuning van gebruikersinteracties, en de
|
||||
flexibiliteit en onderhoudbaarheid van de code optimaal zijn?}"
|
||||
\end{quote}
|
||||
|
||||
Om deze hoofdvraag te beantwoorden worden de volgende deelvragen geformuleerd:
|
||||
|
||||
Voorafgaand aan het project zijn in \autoref{ssec:probleemanalyse} een aantal
|
||||
eisen opgesteld, zoals dat de API moet worden opgebouwd zonder het benut van
|
||||
externe libraries. De volgende deelvraag zal dit beantwoorden:
|
||||
|
||||
\begin{quote}
|
||||
"\textit{Welke stappen zijn nodig om de API vanaf de grond af aan op te bouwen?}"
|
||||
\end{quote}
|
||||
|
||||
Ook zal er gekeken worden welk architectuur het beste bij het project past. Om
|
||||
dit te beantwoorden is de volgende deelvraag geformuleerd:
|
||||
|
||||
\begin{quote}
|
||||
"\textit{Hoe kunnen REST, SOAP, GraphQL, en gRPC worden vergeleken op basis
|
||||
van de gestelde criteria?}"
|
||||
\end{quote}
|
||||
|
||||
@@ -1,17 +1,6 @@
|
||||
\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
|
||||
@@ -29,10 +18,10 @@ web gebaseerde applicaties.
|
||||
\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{Makkelijke implementatie} --- meeste programmeertalen 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
|
||||
eenvoudig horizontaal geschaald worden, echter zal de performance wel slechter
|
||||
zijn dan andere methodes zoals gRPC of GraphQL.\cite{Śliwa_Pańczyk_2021}
|
||||
\end{enumerate}
|
||||
|
||||
@@ -43,8 +32,8 @@ Echter heeft REST ook zijn nadelen, sommige hiervan zijn:
|
||||
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.
|
||||
\item \textbf{Real-time} --- Doordat de connectie niet in stand wordt gehouden nadat
|
||||
de aanvraag is afgehandeld is het minder geschikt voor real-time communicatie.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{SOAP (Simple Object Access Protocol)}
|
||||
@@ -54,7 +43,7 @@ SOAP is een protocol voor uitwisseling van informatie netzoals REST vermeld in
|
||||
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}
|
||||
wat REST niet heeft.\cite{Śliwa_Pańczyk_2021,w3c}
|
||||
|
||||
\subsubsection{Voordelen van SOAP}
|
||||
\begin{enumerate}
|
||||
@@ -86,7 +75,7 @@ Voordelen van GraphQL:
|
||||
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
|
||||
\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}
|
||||
|
||||
@@ -1,73 +0,0 @@
|
||||
\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}
|
||||
@@ -0,0 +1,39 @@
|
||||
\section{Methode}
|
||||
\label{sec:methode}
|
||||
|
||||
\subsection{Welke stappen zijn nodig om de API vanaf de grond af aan op te bouwen?}
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Behoeftenanalyse en Specificatie} --- Identificeer de eisen
|
||||
voor de API, maak een lijst met de vereiste functies.
|
||||
\item \textbf{Architectuurontwerp} --- Definieer de toegestane request types
|
||||
(GET, POST, PUT, DELETE) op de benoemde routes en hun verwachte responses.
|
||||
\item \textbf{UML ontwerpen} -- Maak een klassendiagram voor de API om de
|
||||
structuur van de code te visualiseren.
|
||||
\item \textbf{Implementatie} --- Bouw de API volgens de opgegeven eisen en UML
|
||||
van punt 1, 2 en 3 op.
|
||||
\item \textbf{Testen} --- Ontwikkel unit tests voor alle componenten die
|
||||
door de API worden gebruikt. Verwerk vervolgens ieder probleem dat opkomt.
|
||||
\item \textbf{Onderhoud} --- Monitor de API na de implementatie,
|
||||
pas deze aan op basis van feedback na gebruik. Voeg nieuwe
|
||||
functies toe en verbeter de bestaande functies waar nodig, zonder de
|
||||
bestaande functionaliteit te breken.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Hoe kunnen REST, SOAP, GraphQL, en gRPC worden vergeleken op basis van de gestelde criteria?}
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Vergelijkingscriteria} --- Bepaal de
|
||||
evaluatiecriteria waarop de architecturen vergeleken zullen worden,
|
||||
zoals prestaties, schaalbaarheid en flexibiliteit.
|
||||
\item \textbf{Literatuuronderzoek} --- Voer een literatuuronderzoek uit naar de
|
||||
kenmerken, voor- en nadelen van REST, SOAP, GraphQL, en gRPC.
|
||||
\item \textbf{Theoretische Analyse} --- Analyseer elke API-architectuur op basis
|
||||
van de gedefinieerde projectscriteria. Maak een overzicht van de sterke en
|
||||
zwakke punten van elke architectuur in de context van het robotica project.
|
||||
\item \textbf{Vergelijking} --- Vergelijk de resultaten van de
|
||||
analyse. Weeg de voor- en nadelen van elke API-architectuur af tegen de
|
||||
specifieke eisen van het project.
|
||||
\item \textbf{Conclusie} --- Trek een conclusie over welke API architectuur
|
||||
het meest geschikt is voor het project op basis van de vergelijking.
|
||||
\end{enumerate}
|
||||
@@ -0,0 +1,202 @@
|
||||
\section{Resultaten}
|
||||
\label{sec:resultaten}
|
||||
|
||||
\subsection{Stappen voor het opbouwen van de API vanaf de grond af aan}
|
||||
Voor de ontwikkeling van de API zijn de volgende stappen doorlopen:
|
||||
\begin{enumerate}
|
||||
\item \textbf{Behoeftenanalyse en Specificatie} --- De eerste stap was het
|
||||
identificeren van de eisen voor de API. De volgende eisen zijn opgesteld na
|
||||
aanleiding van de behoeftenanalyse:
|
||||
\begin{enumerate}
|
||||
\item \textbf{Basisfunctionaliteit}
|
||||
\begin{itemize}
|
||||
\item Ondersteunen van communicatie tussen de gebruiker en de robot.
|
||||
\item Mogelijkheid om de robot te besturen en inzicht te krijgen via een
|
||||
webinterface.
|
||||
\end{itemize}
|
||||
\item \textbf{Technische Specificaties}
|
||||
\begin{itemize}
|
||||
\item De API moet worden opgebouwd zonder het gebruik van externe libraries.
|
||||
\item Gebruik van standaard HTTP-methoden (GET, POST, PUT, DELETE).
|
||||
\item Het gebruik van JSON voor gegevensoverdracht.
|
||||
\end{itemize}
|
||||
\item \textbf{Flexibiliteit en Onderhoudbaarheid}
|
||||
\begin{itemize}
|
||||
\item Eenvoudige structuur die gemakkelijk te onderhouden is.
|
||||
\item Flexibel genoeg om toekomstige toevoegingen en aanpassingen te
|
||||
ondersteunen zonder dat de hele codebase herschreven moet worden.
|
||||
\end{itemize}
|
||||
\item \textbf{Gebruikersinterface}
|
||||
\begin{itemize}
|
||||
\item Weergave van verzamelde data in een overzichtelijke manier.
|
||||
\item Presentatie van de mapping en de geplande route van de robot.
|
||||
\item Mogelijkheid om diverse commando’s naar de robot te sturen.
|
||||
\end{itemize}
|
||||
\end{enumerate}
|
||||
\item \textbf{Architectuurontwerp} --- Vervolgens zijn de toegestane request types (GET, POST, PUT, DELETE) gedefinieerd, samen met de benoemde routes en hun verwachte responses. Dit heeft geresulteerd in een gedetailleerd ontwerp van de API-structuur.
|
||||
\begin{itemize}
|
||||
\item \textbf{GET /api/v1/database/metadata}
|
||||
\linebreak Geeft basisinformatie over de database terug.
|
||||
\item \textbf{GET /api/v1/database}
|
||||
\linebreak \textbf{Query Paramters:}
|
||||
\begin{itemize}
|
||||
\item ?id=$<$string$>$ --- De UUIDv4 van de gewensde map.
|
||||
\item ?name=$<$string$>$ --- De naam van de gewensde map.
|
||||
\item ?version=$<$int$>$ --- Het versienummer van de gewensde maps
|
||||
\item ?all=$<$bool$>$ -- Laat alle maps zien
|
||||
\end{itemize}
|
||||
\textbf{Return Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
[
|
||||
{
|
||||
"Id": "<string>",
|
||||
"Name": "<string>",
|
||||
"Version": "<int>",
|
||||
"Objects": "<Array<Array<int, int>>"
|
||||
"Date": "<DateTime>"
|
||||
}, {...}
|
||||
]
|
||||
\end{minted}
|
||||
Geeft een lijst van alle maps terug, of een specifieke map op basis van de query parameters.
|
||||
\item \textbf{POST /api/v1/database}
|
||||
\linebreak \textbf{Request Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"name": "<string>",
|
||||
"objects": "<Array<Array<int, int>>>"
|
||||
}
|
||||
\end{minted}
|
||||
\textbf{Return Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"message": "<success|fail>",
|
||||
"id": "<string>",
|
||||
}
|
||||
\end{minted}
|
||||
Voegt een nieuwe map toe aan de database.
|
||||
\item \textbf{DELETE /api/v1/database}
|
||||
\linebreak \textbf{Query Paramters:}
|
||||
\begin{itemize}
|
||||
\item ?id=$<$string$>$ --- De UUIDv4 van de gewensde map.
|
||||
\item ?name=$<$string$>$ --- De naam van de gewensde map.
|
||||
\end{itemize}
|
||||
Verwijdert de desbetreffende map uit de database.
|
||||
\item \textbf{GET /api/v1/database/path}
|
||||
\linebreak \textbf{Query Paramters:}
|
||||
\begin{itemize}
|
||||
\item ?id=$<$string$>$ --- De UUIDv4 van de gewensde route.
|
||||
\end{itemize}
|
||||
\textbf{Return Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"Id": "<string>",
|
||||
"Objects": "<Array<Array<int, int>>"
|
||||
}
|
||||
\end{minted}
|
||||
\item \textbf{POST /api/v1/database/path}
|
||||
\linebreak \textbf{Request Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"id": "<string>",
|
||||
"objects": "<Array<Array<int, int>>>"
|
||||
}
|
||||
\end{minted}
|
||||
\textbf{Return Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"message": "<success|fail>",
|
||||
"id": "<string>",
|
||||
}
|
||||
\end{minted}
|
||||
Voegt een nieuwe geplande route toe aan de database.
|
||||
\item \textbf{DELETE /api/v1/database/path}
|
||||
\linebreak \textbf{Query Paramters:}
|
||||
\begin{itemize}
|
||||
\item ?id=$<$string$>$ --- De UUIDv4 van de gewensde route.
|
||||
\end{itemize}
|
||||
Verwijdert de desbetreffende route uit de database.
|
||||
\item \textbf{POST /api/v1/database/path/plan}
|
||||
\linebreak \textbf{Request Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"id": "<string>",
|
||||
"objects": "<Array<Array<int, int>>>"
|
||||
}
|
||||
\end{minted}
|
||||
\textbf{Return Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"message": "<success|fail>",
|
||||
"id": "<string>",
|
||||
}
|
||||
\end{minted}
|
||||
Voegt een nieuwe geplande route toe aan de database.
|
||||
\item \textbf{POST /api/v1/roomba/control}
|
||||
\linebreak \textbf{Request Body:}
|
||||
\begin{minted}[linenos,frame=leftline,framesep=3pt]{json}
|
||||
{
|
||||
"command": "<string>"
|
||||
}
|
||||
\end{minted}
|
||||
Proxies het commando naar de Roomba.
|
||||
\end{itemize}
|
||||
\item \textbf{UML ontwerpen} --- Een klassendiagram is gemaakt om de structuur
|
||||
van de code te visualiseren. Dit diagram is te vinden in \autoref{fig:uml}.
|
||||
|
||||
De UML is opgedeeld in drie delen: de HTTP server, het data parsen en de endpoints.
|
||||
De HTTP server is verantwoordelijk voor het ontvangen van de requests en het
|
||||
doorsturen naar de juiste endpoint. Het data parsen zorgt ervoor dat de data
|
||||
correct wordt verwerkt en opgeslagen. De endpoints zijn de verschillende routes
|
||||
die de API aanbiedt en de bijbehorende acties die worden uitgevoerd.
|
||||
\item \textbf{Implementatie} --- De API is opgebouwd volgens de specificaties
|
||||
van de vorige stappen. Er is gebruik gemaakt van Csharp zonder externe libraries
|
||||
om de functionaliteiten van de API te implementeren.
|
||||
\item \textbf{Testen} --- Er zijn unit tests ontwikkeld voor alle componenten
|
||||
die door de API worden gebruikt. Eventuele problemen die tijdens het testen naar
|
||||
voren kwamen zijn verwerkt en opgelost.
|
||||
\item \textbf{Onderhoud} --- Na implementatie is de API gemonitord en aangepast
|
||||
op basis van feedback. Nieuwe functies zijn toegevoegd en bestaande functies
|
||||
zijn verbeterd waar nodig, zonder de bestaande functionaliteit te breken.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Vergelijking van REST, SOAP, GraphQL, en gRPC op basis van gestelde criteria}
|
||||
De API architecturen zijn vergeleken op basis van de volgende criteria:
|
||||
prestaties, schaalbaarheid, flexibiliteit, onderhoudbaarheid, en geschiktheid
|
||||
voor de projectseisen.
|
||||
Hieronder volgt een samenvatting van de resultaten verzameld in
|
||||
\autoref{sec:theoretisch kader}.
|
||||
|
||||
\subsubsection{REST}
|
||||
\begin{itemize}
|
||||
\item \textbf{Voordelen}: REST heeft een eenvoudige structuur, maakt gebruik van standaard HTTP-methoden en JSON, en is gemakkelijk te implementeren. Het is goed schaalbaar door zijn stateless karakter.
|
||||
\item \textbf{Nadelen}: REST kan overbodige data teruggeven, is minder geschikt voor complexe query’s, en biedt geen directe ondersteuning voor documentatie en real-time communicatie.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{SOAP}
|
||||
\begin{itemize}
|
||||
\item \textbf{Voordelen}: SOAP biedt beveiligingsfuncties en ondersteuning
|
||||
voor ACID-transacties. Het maakt gebruik van XML voor berichtuitwisseling en
|
||||
ondersteunt verschillende transportprotocollen.
|
||||
\item \textbf{Nadelen}: SOAP heeft een ingewikkeld formaat door de
|
||||
XML-berichten, wat resulteert in een hogere complexiteit vergeleken met REST
|
||||
waar meerdere typfouten op kunnen treden.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{GraphQL}
|
||||
\begin{itemize}
|
||||
\item \textbf{Voordelen}: GraphQL biedt efficiëntie door de mogelijkheid om
|
||||
specifieke sets data op te vragen, wat over-fetching en under-fetching
|
||||
vermindert. Ook biedt GraphQL type controle door middel van schema's.
|
||||
\item \textbf{Nadelen}: De serverimplementatie van GraphQL is complexer,
|
||||
waardoor het moeilijker kan zijn om zonder externe libraries te implementeren.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{gRPC}
|
||||
\begin{itemize}
|
||||
\item \textbf{Voordelen}: gRPC biedt hoge prestaties door het gebruik van
|
||||
Protocol Buffers, en is zeer geschikt voor real-time communicatie door
|
||||
HTTP/2. Het biedt ook functies zoals load balancing en monitoring.
|
||||
\item \textbf{Nadelen}: gRPC is complexer op te zetten en te debuggen, en
|
||||
heeft limitaties door het gebruik van HTTP/2, wat niet compatibel is met
|
||||
oudere web browsers. Ook heeft gRPC net als GraphQL een complexe serverimplementatie.
|
||||
\end{itemize}
|
||||
@@ -0,0 +1,33 @@
|
||||
\section{Conclusie}
|
||||
\label{sec:conclusie}
|
||||
|
||||
De hoofdvraag van dit onderzoek luidt:
|
||||
|
||||
\begin{quote}
|
||||
"\textit{Welke API architectuur is het beste geschikt voor de specifieke eisen van het project, waarbij de communicatie tussen verschillende softwarecomponenten, de ondersteuning van gebruikersinteracties, en de flexibiliteit en onderhoudbaarheid van de code optimaal zijn?}"
|
||||
\end{quote}
|
||||
|
||||
Voor het uiteindelijke project zal er gebruik worden gemaakt van \textbf{REST}
|
||||
als API architectuur. REST is de meest geschikte keuze voor het project, omdat
|
||||
het voldoet aan de eisen van het project en het ontwikkelen van de API zonder
|
||||
externe libraries mogelijk maakt. REST is eenvoudig te implementeren en biedt
|
||||
een breed scala aan mogelijkheden voor communicatie tussen verschillende
|
||||
componenten.
|
||||
|
||||
Om deze hoofdvraag te beantwoorden, zijn de volgende deelvragen geformuleerd:
|
||||
|
||||
\begin{quote}
|
||||
"\textit{Welke stappen zijn nodig om de API vanaf de grond af aan op te bouwen?}"
|
||||
\end{quote}
|
||||
|
||||
Uit de ontwikkeling van de API blijkt dat er geen nood is voor specifieke
|
||||
dataselectie, wat GraphQL juist zo sterk maakt. Ook is er geen nood voor
|
||||
real-time communicatie of authenticatie.
|
||||
|
||||
\begin{quote}
|
||||
"\textit{Hoe kunnen REST, SOAP, GraphQL, en gRPC worden vergeleken op basis van de gestelde criteria?}"
|
||||
\end{quote}
|
||||
|
||||
Het project stelt een aantal eisen aan de API-architectuur, waaronder het
|
||||
ontwikkelen zonder externe libraries. Uit \autoref{sec:resultaten} blijkt dat
|
||||
\textbf{REST} de meest geschikte keuze is op basis van de gestelde criteria.
|
||||
@@ -0,0 +1,29 @@
|
||||
\newpage
|
||||
\section{Bijlage}
|
||||
|
||||
\subsection*{User Story}
|
||||
Nadat de robot de ruimte in kaart heeft gebracht en de optimale route bepaald
|
||||
heeft, moet dit allemaal op een manier toegankelijk worden gesteld aan de
|
||||
gebruiker.
|
||||
|
||||
Dit zal gedaan worden d.m.v. het hosten van een web interface op een aparte
|
||||
“server PI”. Deze PI zal vervolgens ook een manier van communicatie opstellen
|
||||
met de roomba PI om vervolgens hun informatie met elkaar te delen.
|
||||
|
||||
\subsection*{UML modellen}
|
||||
\label{ssec:uml model voor de api server}
|
||||
\begin{figure}[H]
|
||||
\includegraphics[width=1\textwidth]{uml-v1.jpg}
|
||||
\caption{1\textsuperscript{e} versie UML model.}
|
||||
\label{fig:umlv1}
|
||||
\end{figure}
|
||||
|
||||
\newpage
|
||||
|
||||
\begin{figure}[H]
|
||||
\includegraphics[width=1\textwidth]{uml.jpg}
|
||||
\caption{Uiteindelijke versie UML model.}
|
||||
\label{fig:uml}
|
||||
\end{figure}
|
||||
|
||||
\newpage
|
||||
Reference in New Issue
Block a user