1. #1471
    bealzebub's Avatar
    Registered
    28/06/06
    Location
    Gent
    Posts
    376
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by Moto View Post
    This quote is hidden because you are ignoring this member. Show
    nogal logisch dan dat wanneer ge van een relationele naar een in-memory document-db gaat ook eerst eens wat artikels leest
    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  

  2. #1472
    Moto's Avatar
    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.io
    no votes  

  3. #1473
    W0utR's Avatar
    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  

  4. #1474
    Albireo's Avatar
    Registered
    21/10/05
    Location
    Herentals
    Posts
    1,515
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    Reputation
    2/13
    Quote Originally Posted by adrianhates View Post
    This quote is hidden because you are ignoring this member. Show
    tegenwoordig heb je met echt belachelijk weinig werk een goeie RESTful service opgezet.
    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  

  5. #1475
    bealzebub's Avatar
    Registered
    28/06/06
    Location
    Gent
    Posts
    376
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    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  

  6. #1476
    profound's Avatar
    Registered
    13/12/08
    Location
    Dendermonde
    Posts
    3,899
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    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  

  7. #1477
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    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
    Als het snel en simpler kan zonder Spring, dumpen die handel
    Doe redelijk wat .Net en nog nooit een DI framework gebruikt. Tightly coupled code FTW
    no votes  

  8. #1478

    Registered
    30/05/05
    Posts
    1,930
    iTrader
    13 (93%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by profound View Post
    This quote is hidden because you are ignoring this member. Show
    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...
    Hier hebben we nog een project gebouwd met Struts1 en Struts2, verschrikkelijk gewoon die frameworks. Vooral voor frontend design.
    no votes  

  9. #1479
    profound's Avatar
    Registered
    13/12/08
    Location
    Dendermonde
    Posts
    3,899
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by Moto View Post
    This quote is hidden because you are ignoring this member. Show
    Als het snel en simpler kan zonder Spring, dumpen die handel
    Het 'probleem' is echter dat veel bedrijven nog steeds werken met spring en het in de java-wereld dus nog altijd veel gevraagd is. Anders had ik dit kleine side-projectje wel in Play! gedaan
    no votes  

  10. #1480
    Albireo's Avatar
    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

    Quote Originally Posted by bealzebub View Post
    This quote is hidden because you are ignoring this member. Show
    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.

    <!--knip-->
    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  

  11. #1481
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    De vraag is, is het sop de kool waard?
    Zolang de interface niet public is maakt het toch allemaal niet echt een bal uit als dat

    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 detailleke
    no votes  

  12. #1482
    bealzebub's Avatar
    Registered
    28/06/06
    Location
    Gent
    Posts
    376
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    GET http://mijnapp.be/view-people.aspx voor een lijst van personen
    POST http://mijnapp.be/insert-people.aspx voor een nieuwe persoon
    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.

    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    POST http://mijnapp.be/update-people.aspx?id=123 om een persoon te wijzigen
    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 :-)

    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    Zoals?

    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    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).
    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).

    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    De vraag is, is het sop de kool waard?
    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.

    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    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  

  13. #1483
    Albireo's Avatar
    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  

  14. #1484
    profound's Avatar
    Registered
    13/12/08
    Location
    Dendermonde
    Posts
    3,899
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    Vergeet vooral nie dat REST een middel en geen doel is
    no votes  

  15. #1485
    profound's Avatar
    Registered
    13/12/08
    Location
    Dendermonde
    Posts
    3,899
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    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  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in