Samenvatting Mobile Development (Node & Express - API)

Mobile Development

Rest API’s
 REST
o Representational state transfer
 Een REST API is een architecturaal patroon voor web API’s
o Het is geen framework, programmeertaal, standaard of protocol
o Het kan dus geïmplementeerd worden in elke programmeertaal
o Er zijn verder ook geen limieten op de structuur van de teruggegeven data
 Deze kan als JSON, HTML, Plain Text, XML, … teruggegeven worden
 JSON is het populairste
 Omdat RESR geen echte standaard is, zijn de vereisten voor een REST API ook
niet sterk afgebakend
o Een REST API moet voldoen aan volgende vereisten
 Uniforme interface
 Alle API requests voor een resource
o een rij in een tabel
o een document in een document database
geven op dezelfde manier terug
o Dit wil zeggen dat de volledige API ofwel in JSON-
formaat ofwel in XML-formaat aangeboden kan
worden, maar geen mix van beiden
 Het gekozen formaat hoeft niet overeen te
komen met het formaat dat intern door de
server gebruikt wordt
 De resource die teruggegeven wordt door de API bevat alle
nodige informatie om de resources aan te passen of te
verwijderen
 Elke resource is uniek en kan met één URL geïdentificeerd
worden
 Hypermedia as the engine of application state
o HATEOAS

,  De resources moeten een overzicht geven van
welke andere resources er beschikbaar zijn aan de
hand van hyperlinks
 Net zoals bij een browser moet er een, bij een
correctie HATEAOS implementatie, slechts één URL
gekend zijn
 De andere kunnen bezocht worden door
“door te klikken” in het antwoord dat de
server geeft op een request voor de root-url
 Wordt echter weinig gebruikt in productie omdat de
meeste API’s bedoeld zijn voor programmeur en
RUD-operaties moten ondersteunen
 Omdat er op verschillende pagina’ in de
client-applicatie verschillende acties
ondersteund moeten worden en omdat deze
pagina’s rechtstreek bezocht kunnen worden
i.p.v. via de root pagina te gaan, moet de
applicatie de URL’s van de API sowieso
kennen
 Client-server met zwakke coupling
 De client en server moeten zo weinig mogelijk van elkaar
weten
o De client en de server kunnen onafhankelijk van
elkaar ontwikkeld worden en communiceren enkel via
HTTP(S)
 Statelessness
 Elk request van de client naar de server moet alle informatie
bevatten om het request correct af te handelen
 De server mag geen data bewaren over de state op de client,
er zijn dus geen server-side sessions
 Caching
 Waar mogelijk moeten resources gechached worden
 Elk antwoord op een request moet informatie bevatten die
aangeeft of een resource client-side gechached mag worden
of niet
 Layered system architecture
 Noch de client, nog de server mag er van uitgaan dat de
communicatie tussen de client en server rechtstreeks
gebeurd
o Deze communicatie kan eventueel via een derde partij
gaan



2

,  Deze architectuur maakt het mogelijk om, op elk moment,
een proxy of load balancer toe te voegen tussen de client en
de server




3

, Rest Requests
 Voor elke resource zijn CRUD-operaties beschikbaar en met elke CRUD-operatie
komt een HTTP-methode overeen
o CRUD-operaties
 HTTP-methode
 CREATE
o POST
 READ
o GET
 UPDATE
o PUT
 DELETE
o DELETE
 Elke request naar de API heeft vier onderdelen
o Operatie
 Een HTTP-methode
o Endpoint
 Het laatste deel van URL, voor onze API dus /api/*
o Parameters
 Data die door de API gebruikt wordt om het request af te handelen
o Header
 HTTP-headers die zaken zoals authentication data bevatten
 Afhankelijk van de methode worden er parameters toegevoegd in de body of
worden er een parameter toegevoegd in de URL
o Voor PUT en POST wordt body data gebruikt en voor GET, PUT en DELETE
een URL-parameter


Node & Express
 API’s bouwen via Node.js en met behulp van het Express framework
o Express is een minimalistisch webserver-framework voor Node
 Hiermee definiëren we dus e routes die via onze API beschikbaar
zijn




4