Will Fris's WordPress Weblog











{20120820}   (web)server-client-interactie

Tijdens het schrijven van code voor het web vraag ik mij nogal eens af hoe ik het httprequest
zo interpreteer dat ik overzichtelijk en begrijpelijk de stukken code kan aanroepen waarmee ik de httpresponse samenstel.

Of korter; hoe bepaal ik hoe en waarmee ik mijn code laat antwoorden?
Het `hoe` is wat betreft een httprequest snel beantwoord, namelijk door middel van een httpresponse.
Dan het `waarmee`; ook die vraag valt snel te beantwoorden de uitkomst zal namelijk een httpresponse zijn.

Met deze twee antwoorden heb ik de vraag volledig beantwoord. Maar het gaat me om dat wat achter die httpresponse ligt. Ik ben op zoek naar hoe een httpresponse wordt opgebouwd door middel van het aanroepen van verschillende codes/instructies.

Wanneer ik zelf antwoord probeer te geven op een vraag, volg ik vaak een vast patroon.

  1. Ik ontvang een vraag.
  2. Ik interpreteer die vraag.
  3. Ik zoek mijn antwoord op die vraag.
  4. Ik stel mijn antwoord samen.
  5. Ik geef mijn antwoord.

En dat zoeken van mijn antwoord is essentieel in de vraag die ik heb.

Nou ik heb er wat over nagedacht en het met anderen gehad over deze vraag en dit artikel. Uiteindelijk blijkt het het handigste te zijn om voor een antwoord te redeneren vanuit de vraag die je drijft tot zoeken.

In mijn geval is dat het schrijven van een Request-klasse, een set van codes die bepalen en daarna aan kunnen geven wat het is dat de gebruiker, browser, http-user-agent wil. Hoofdzakelijk beschouw ik de interactie op het web als een interactie met het databasemodel en daarmee kom ik al snel uit op CRUD, vier methodes die alle mogelijke bewerkingsacties op een entiteit, gegevensset aangeven. CRUD staat voor Create Read Update Delete, oftewel aanmaken, uitlezen, wijzigen en verwijderen, uiteraard van een entiteit, een weerspiegeling van de gegevensset die men graag door de applicatie laat onthouden.

Ik heb op verschillende plekken op het internet een brug geslagen zien worden tussen de verschillende CRUD-methoden en http-request headers, te weten: Create – POST , Read – GET , Update – PUT , Delete – DELETE. Bijkomend wordt ook vaak de vergelijking getrokken met de verschillende SQL-instructies, ik laat ze hier ook even naar voren komen; Create – INSERT , Read – SELECT , Update – UPDATE , Delete – DELETE.
De meeste browsers ondersteunen echter enkel POST en GET als gebruikte waardes voor het method-attribuut van een formulier. Ik kies er daarom voor om in het geval van een Read een GET-request te doen, elke andere actie uit het CRUD-arsenaal dient een POST-request te zijn. Een POST-request zonder valide waarde voor een waardepaar met de index/key: ‘method’ zal gelden als een Create-opdracht, een instructie om iets aan te maken. Is er een method-waardepaar aanwezig en is de waarde daarvan PUT of DELETE dan wil ik er van uitgaan dat de http-user-agent een opdracht aangeeft om de aangesproken resource bij te werken of respectievelijk te verwijderen.
Met deze vier acties geef ik de gebruiker de mogelijkheid om verzoeken te doen op de publieke resources van de server.

Een vraag die dan nog rest is hoe bepaald kan worden op welk object de gebruiker een actie probeert uit te oefenen. De aangegeven locatie, URL/URI is hier de aangewezen kandidaat om een identificerende rol te vervullen. En dit is dan misschien ook het uitgelezen moment om er op te wijzen dat die locatie geen directe relatie hoeft te hebben met één bestand op de harde schijf van de server of met een tabel of rij in de database. De locatie is een weerspiegeling van een object dat aan de client kenbaar is gemaakt en wat een voor de client logische set aan gegevens bevat.

De basisreactie op een vraag is dat het antwoord niet bekend is, de uitzonderingen daarop zijn die gevallen waarin er wel een antwoord gegeven kan worden. Datzelfde zal ook gelden ovor resources/objecten die kenbaar gemaakt worden op het web. Een vraag die de applicatie/code dus zal moeten beantwoorden is of het bevraagde object bekend is binnen de applicatie als object waar de gevraagde actie op uitgevoerd kan worden.

Er zijn overigens verschillende manieren om zo’n bevraagde resource/object uit de opgevraagde locatie te halen. Ik heb daarom (op dit moment nog in grove lijnen) op http://tests.willfris.nl/server_vars/ uitgewerkt welke verschillende mogelijkheden ik op dit moment ken voor php en apache.

Om nu weer terug te komen op de verschillende stukken code die aangeroepen dienen te worden; uiteraard verschilt dit voor de verschillende objecten die opgevraagd kunnen worden. Maar er zijn ook stukken code die een object ‘overstijgen’. En in het geval van dat soort objecten krijgen we dan ook te maken de `statelessness` van het http, de regel dat elk http-verzoek losstaand zou moeten kunnen worden gedaan(vier werkwoorden achter elkaar w00h00 :s). Het wellicht duidelijkste voorbeeld van een stuk code dat het object overstijgt is het vasthouden van de gebruikersgegevens, die vaak worden bijgehouden in een (sessie)bestanden. Het zal namelijk de voorkeur genieten om zo’n sessie ook actief te houden wanneer de gebruiker om een object vraagt dat geen login/sessie vereist.

Ik denk dat ik hiermeer in grote lijnen een rommelige overview heb geschetst van wat ik verwacht van een Request-klasse maar hoop mettertijd suggesties voor verbetering te krijgen en daarmee inzicht en enthousiasme om dit daar op aan te passen 🙂

Peace out.

Gehanteerde begrippen

Een httprequest
is een vraag die door de (http-)client( de user-agent( de browser)) gesteld wordt en voldoet  aan de in het hypertext transfer protocol daarvoor opgestelde condities.
Een httpresponse
is een antwoord dat door de (http-)server( de webserver( apache)) gegeven wordt en voldoet aan de in het hypertext transfer protocol daarvoor opgestelde condities.
Een server
is in dit geval een programma dat voorziet in een bepaalde dienst danwel functionaliteit.
Advertisements


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

et cetera
%d bloggers like this: