Thread: De koffiepauzehoek
-
08-01-2014, 16:17 #1471
Alleen is mongodb geen inmemory db
Het heeft een inmemory cache, maar da's verre van een inmemory db. Nu goed, we zijn hier aan het nitpicken over terminologie.
Redis daarentegen is bv. echt wel inmemory met persistence via interval/treshold (waarbij je gaat instellen wat de verschillende tresholds voor persistence zijn). Wij gebruiken redis bv voor session en websocket management in een geclusterde nodejs omgeving zodat die gedeeld kunnen worden over de verschillende instances. Dat is ook één van de toepassingen waarvoor redis een heel goeie oplossing is.no votes
-
-
08-01-2014, 17:37 #1472Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
ja die connect-redis,
Indertijd ook redis gebruikt voor simpele pub/sub tussen mijn C# app en een simpel node.js realtime logging site met socket.iono votes
-
09-01-2014, 11:27 #1473Member
- Registered
- 16/04/08
- Location
- Hong Kong
- Posts
- 1,989
- iTrader
- 6 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 7/9
Man man, begin het hier stillekes aan moe te worden op het werk (allez, ben het al 3 maand lang moe), de persoon die zichzelf designer noemt doet dus eigenlijk niet meer dan foto's aanpassen en uitvoeren in illustrator wat andere mensen vragen.
Als hij zelf iets moet designen is het ronduit lelijk of krijgt hij zoveel commentaar dat het er na 5 dagen wat deftig uitziet.
'T is natuurlijk wel zo iemand die met iedereen overeenkomt omdat hij iedereen altijd gelijk geeft, hij heeft dus totaal geen eigen mening, als één van de managers een suggestie heeft zal hij er altijd mee akkoord gaan, als ik een suggestie geeft ook, als iemand buiten ons team iets zegt gaat hij ook akkoord.
Vanaf ik dat doorhad begon ik mij daar totaal aan te ergeren, het ergste vanal is dat hij gewoon ongeloofelijk traag is, images exporteren duurt vaak uren terwijl ik zoiets op 5 minuten kan doen.
Aangeleverde mockups zijn gewoon .jpg files en ik mag dan maar uitzoeken welke fonts en kleuren hij gebruikt. (en het gaat er niet in dat dit gewoon puur tijdverlies is, maarja dat zijn gewoontes van voordat ik hier was ...)
Hetzelfde probleem met schrijven, teksten nalezen? Dat zullen we wel doen als alles op staging staat. Final copy aanleveren? Waarschijnlijk een uurtje voordat de deadline is.
Maar goed, hetgene dat ik nu geleerd heb op 8 maand, word nooit in-house developer, de meeste mensen zijn echt dom en leveren slecht werk.
</rant>no votes
-
09-01-2014, 20:49 #1474Member
- Registered
- 21/10/05
- Location
- Herentals
- Posts
- 1,515
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 2/13
Ik vroeg me zo af, als jullie het over REST hebben, hoe ziet dat er dan uit in de praktijk? Als ik een formulier via ajax naar een Generic Handler (ASP.NET) stuur die alles in een database zet en op een andere pagina een andere Generic Handler aanroep die alles uit de database haalt en via JSON naar m'n pagina stuurt ben ik dan RESTful bezig???
Als ik de Wikipedia pagina zo lees, is niet elke webapplicatie RESTful (tenzij die sessions gebruiken)?Last edited by Albireo; 09-01-2014 at 22:32.
"And we wept, Precious. We wept to be so alone." --- Gollum
"Sometimes there are no words. No clever quotes to neatly sum up what happened that day. Sometimes, the day just . . . ends." --- Hotch (Criminal Minds)no votes
-
09-01-2014, 23:45 #1475
REST is een redelijk wijd en eigenlijk in webdevelopment termen al een oud concept en het is breder dan alleen maar webservices, maar daarvoor is het wel het meest gekend.
De opkomst van REST heeft veel te maken met de voordelen die het kan bieden: het schaalt makkelijk, het is een stuk compacter en performanter dan bv. SOAP en het past perfect in het plaatje van de meeste serverside MVC frameworks en HTTP en ook de frontend frameworks zoals Backbone of Ember kunnen makkelijk RESTful conventies automatiseren. Het is immers makkelijk om bv uit "GET /companies/123.json" af te leiden dat je het bedrijf met ID 123 wil uit de database halen en als JSON wil weergegeven zien.
REST heeft op zich niets met sessions te maken, ze worden zelfs dikwijls zonder sessions maar bv. via een API key in de header aangesproken. In tegenstelling tot SOAP is het ook geen protocol maar eerder een bepaalde architectuur, omdat het geen officiële standaard is. Het protocol om REST over te transporteren is HTTP(S). Daarom is het ook moeilijk om precies uit te leggen hoe een RESTful protocol er precies uitziet, je kan dat zelf beslissen, zolang het maar de principes van REST gebruikt.
Een van de meest belangrijke principes is dat je "resources" gaat exposen via een unieke identifier, bij HTTP de URL. Het manipuleren van die resources gebeurt via de mogelijkheden van een standaardinterface. De representatie is ook iets wat meegegeven wordt via het onderliggend protocol. Dat kan als extensie (resource.json) of via een Accept header (application/json). Dat moet ook niet noodzakelijk JSON of XML zijn, alhoewel die het populairst zijn. Dat kan bij wijze van spreken perfect HTML, SVG, CSV of zelfs PDF zijn.
Een mogelijke REST webservice zou als volgt in mekaar kunnen zitten:
Collectie personen via URL http://mijnapp.be/people met als HTTP method:
- GET Haal een lijst van de personen op
- PUT/PATCH Pas een ganse lijst van personen aan
- POST Maak een nieuwe persoon of personen aan
- DELETE Wis een lijst van personen
Individuele personen via URL http://mijnapp.be/people/123 met als HTTP method:
- GET Haal de gegevens van de persoon op
- PUT/PATCH Pas een bestaande persoon aan
- POST Wordt niet gebruikt
- DELETE Wis de persoon
no votes
-
10-01-2014, 01:56 #1476
Mooi uitgelegd!

On another note; zijn hier mensen met verstand van Spring, normaal werk ik er wel graag mee, maar soms ben ik al dat geconfigureer zo beu, voelt heel log en omslachtig aan
En ik zit met een probleem...no votes
-
10-01-2014, 02:58 #1477Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
Als het snel en simpler kan zonder Spring, dumpen die handelzijn hier mensen met verstand van Spring, normaal werk ik er wel graag mee, maar soms ben ik al dat geconfigureer zo beu, voelt heel log en omslachtig aan
Doe redelijk wat .Net en nog nooit een DI framework gebruikt. Tightly coupled code FTWno votes
-
10-01-2014, 10:45 #1478Member
- Registered
- 30/05/05
- Posts
- 1,930
- iTrader
- 13 (93%)
- Mentioned
- 0 Post(s)
no votes
-
10-01-2014, 11:53 #1479no votes
-
10-01-2014, 13:48 #1480Member
- Registered
- 21/10/05
- Location
- Herentals
- Posts
- 1,515
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 2/13
Alvast bedankt voor de uitgebreide uitleg

Het begint me min of meer te dagen.
De traditionele manier van werken in webdelopment is dat je meerdere URL's gebruikt en die via POST of GET aanspreekt
bv.
GET http://mijnapp.be/view-people.aspx voor een lijst van personen
POST http://mijnapp.be/insert-people.aspx voor een nieuwe persoon
POST http://mijnapp.be/update-people.aspx?id=123 om een persoon te wijzigen
etc...
Zo hebben ze het mij aangeleerd en zo ziet elke tutorial op het web er ook uit. Maar ik kan de elegantie van de REST-methode zien. Ik kan ook een paar praktische moeilijkheden zien.
Ik heb PUT en DELETE nog NOOIT gebruikt. Ik zou eigenlijk niet eens weten hoe je die gebruikt in PHP of ASP.NET. Je hebt daar respectievelijk $_POST en $_GET versus Request.Form en Request.QueryString, maar niets om PUT of DELETE te verwerken (ik vermoed dat je dan low level methods moet bovenhalen, zoals HttpWebRequest).
De vraag is, is het sop de kool waard? En is het gebruik van PUT en DELETE een regel, of eerder een richtlijn?
De reden dat ik over sessies begon, is omdat die als ik het allemaal goed begrepen heb, het REST-principe schenden. REST is stateless en sessies introduceren net state.Last edited by Albireo; 10-01-2014 at 14:00.
"And we wept, Precious. We wept to be so alone." --- Gollum
"Sometimes there are no words. No clever quotes to neatly sum up what happened that day. Sometimes, the day just . . . ends." --- Hotch (Criminal Minds)no votes
-
10-01-2014, 14:12 #1481Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
Zolang de interface niet public is maakt het toch allemaal niet echt een bal uit als datDe vraag is, is het sop de kool waard?
http://mijnapp.be/get-people.aspx?id=123
of
http://mijnapp.be/people/123
is
tov zorgen dat uw backend performant en stabiel is en uw frontend een nieuw UX-wonder is is
dat uiteindelijk een onbenullig implementatie detaillekeno votes
-
10-01-2014, 14:41 #1482
In bovenstaande twee voorbeelden heb je redundant info, want het werkwoord (GET/POST) drukt eigenlijk al die view en insert uit. Eigenlijk is de resource "people" in combinatie met het werkwoord GET of POST designtechnisch gezien een stuk properder.
En hier komt dus het verschil met een REST service pas echt naar boven. Dit is dus de "old-school" manier van werken. Elke URL vertegenwoordigt een "action" en een "target". Is dit fout? Nee. Laat dat duidelijk zijn. Mijn ervaring met derde partijen die SOAP of HTTP based target-action of een variant gebruiken voor webservices al heel snel vervallen in request creep.
Bv.
http://mijnapp.be/update-companies-for-person?id=123
http://mijnapp.be/make-person-inactive?id=123
…
Ze gaan m.a.w. acties op een record als aparte url gaan exposen omdat dat binnen die action-based mindset perfect logisch klinkt.
In een REST setup zijn de twee URLs gewoon weeral een PUT op http://mijnapp.be/people/123 (of http://mijnapp.be/people?id=123, hoewel ik niet echt voor query parameters in die context ben), waarbij je in je POST params respectievelijk een array van companies doorgeeft of inactive=true.
T is maar een voorbeeld, maar ik zie echt wel dikwijls een wildgroei van calls waarbij verschillende mensen dan ook nog eens verschillende implementaties of meningen over hoe het juist moet gebeuren erop nahouden. Met REST kan dat ook gebeuren, maar de kans is een pak kleiner omdat je met een duidelijke conventie zit (die dikwijls dan nog door generische code zal geïmplementeerd worden en gewoon werken zonder dat er voor elke resource iets moet geschreven worden).
Trouwens, je moet voor REST zelfs absoluut niet die PUT/DELETE gebruiken. Je kan nog altijd die werkwoorden in de URL voorzien (je zal wel nog altijd GET en POST gebruiken, maar dat heeft dan meer met de potentie van die werkwoorden te maken). Om te zien hoe je nog altijd RESTful kan werken zonder die HTTP verbs verwijs ik naar de aanvulling onderaan deze post. Je zal misschien denken: dit is toch identiek aan wat ik doe, maar dat is niet zo. Het werkwoord is een aparte entiteit binnen de URL:
- Jij: view-people.aspx, create-people.aspx, update-people.aspx
- Zij: people/ , people/create, people/update
T is moeilijk om echt 100% duidelijk uit te leggen, ofwel klikt het ofwel klikt het niet :-)
Zoals?
rest - PHP detecting request type (GET, POST, PUT or DELETE) - Stack Overflow
Er zal voor ASP ook wel genoeg te vinden zijn daarover. Alle webservers de dag van vandaag kennen PUT/PATCH en DELETE (en voor de oude kan het via een automatische parameter injectie gesimuleerd worden, Rails zal bv een POST doen met _method=PUT in de parameters).
Dat is aan jou om te beslissen. Voor ons biedt REST in elk geval een meerwaarde omdat we er minder code voor moeten schrijven in de backend (generische code doet gans de REST routing en setup) en dat de frontend (Backbone of Ember based meestal) al voorzien zijn op de REST conventies.
In de populaire MVC omgevingen mapt het gewoon perfect op de model-view-controller conventie. Elk model is perfect als een resource te zien, de controllers kunnen perfect op een model mappen en de views kunnen perfect afgeleid worden uit extensie of Accept headers. Je kan natuurlijk ook wel nog altijd resources hebben die niet op een model mappen, zoals bv. cookie-based sessions.
Wel… ja en nee. Als je state wil hebben in REST moet je dat gewoon bij elke request via die unique resource identifiers kunnen doorgeven en dat kunnen perfect via cookies ofzo. Het is een misvatting dat je aan de serverzijde geen state management mag doen.
Laat ons bv. een shopping cart nemen. Het is dus niet zo dat je via REST geen items kan toevoegen/verwijderen aan die persoonlijke shopping cart.
In dat geval moet je shopping cart als een resource zien en heb je een URL zoals
http://mijnapp.be/shopping_cart
Ook daarop kan je weer die GET/POST/DELETE/PATCH/PUT methodiek toepassen voor create/update/delete. Maar een shopping cart is nog altijd persoonlijk, dus zal je via de request headers nog altijd een session maintainen en bij elke request die doorgeven. Dat kan zelfs een cookie value zijn, maar ook perfect iets anders. Zolang de combinatie van alles maar een unieke endpoint heeft en consistent voor alles werkt.
Als we dan toch over sessies bezig zijn, hoe implementeer je sessies dan in een RESTful omgeving? Een sessie is een resource, inloggen is een sessie aanmaken, uitloggen is je sessie afsluiten. Je kan in dit geval dus perfect een url http://mijnapp.be/sessions hebben waar je een POST naar doet om de sessie te maken (met login en paswoord als params) en een DELETE gebruiken naar die URL om uit te loggen. Net zoals al de rest is dat dus een Representational State Transfer. Het is gewoon consistent.
REST statelessness gaat dus niet over state management aan de serverzijde maar wel over het uniek en dus stateless identificeren van een entiteit/resource.
Aanvulling: bekijk de screencast op http://sailsjs.org eens om een praktijkvoorbeeld te zien over hoe REST conventies de hoeveelheid code kunnen reduceren.Last edited by bealzebub; 10-01-2014 at 14:56.
no votes
-
10-01-2014, 19:20 #1483Member
- Registered
- 21/10/05
- Location
- Herentals
- Posts
- 1,515
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 2/13
'k Zal het dit weekend eens allemaal rustig gaan uitzoeken en zien wat REST voor mij kan doen. Bedankt.

(in ASP.NET heb je de Web API voor REST-toepassingen, heb ik net ontdekt)"And we wept, Precious. We wept to be so alone." --- Gollum
"Sometimes there are no words. No clever quotes to neatly sum up what happened that day. Sometimes, the day just . . . ends." --- Hotch (Criminal Minds)no votes
-
10-01-2014, 21:41 #1484
Vergeet vooral nie dat REST een middel en geen doel is
no votes
-
14-01-2014, 02:33 #1485
Hoe zouden jullie volgend probleem aanpakken;
Ik heb een site waar je kleine post-it notes kan maken en toevoegen aan een soort van 'bord aan de muur'. Deze zijn ook allemaal draggable. Via een knop kan je notes aanmaken en toevoegen, die gebeurt via ajax. Mijn probleem is dat wanneer iemand via ajax een note toevoegt, er iemand anders misschien ook al notes heeft toegevoegd, en ik dus ook die nieuwe notes wil meegeven. Maar hoe weet ik of hoe kan ik weten welke notes er al op de site staan?
Ik had gedacht om alles in een arraylist bij te houden, en bij elke nieuwe note die toegevoegd wordt alle notes op te halen en te gaan kijken of ze al in de arraylist zitten, maar dit lijkt mij zo omslachtig....iemand met een betere oplossing?
edit: misschien effe vermelden dat alle notes in een DB worden opgeslagen ^^Last edited by profound; 14-01-2014 at 14:58.
no votes

