CAPTCHA wordt veel gebruikt om spam tegen te gaan. Er zijn veel implementaties van, maar nu is er ook een nuttige versie, die helpt om boeken te digitaliseren. En ik hou van boeken, zowel stoffige papieren versies als digitale exemplaren in de vorm van PDF.
De automagische vertaling van boeken is een probleem, maar met behulp van ReCAPTCHA wordt de hulp van mensen in geroepen om een vertaling aan te leveren. En er is een makkelijke PHP library gemaakt zodat je het snel en makkelijk op je website kan gebruiken.
Dus snel en simpel en behulpzaam.
Check de ReCAPTCHA website!
Friday 25 May 2007
Thursday 24 May 2007
REST en PHP
REST is cool.
Voor wie het niet kent; REST houdt in dat resources via URL's worden aangeboden en kunnen worden gemodificeerd via het HTTP. Goed dat is misschien voor de meesten mensen abracadabra, daarom een kleine uitleg. Allereerst moet ik wat vertellen over Web Services. Web Services zijn diensten die een persoon of bedrijf aanbiedt waarmee andere personen of websites iets doen. Zoals SOAP. Via SOAP koppelingen of RPC's worden gegevens opgevraagd en soms kunnen er zelfs gegevens worden weggeschreven. Meestal zijn deze methodes lelijk en ondoorzichtig voor een gebruiker.
REST is een architectuur stijl voor het maken van een webapplicatie, het defineert dus geen protocol maar een manier om met elkaar te communiceren. Een URL wordt aangeroepen en een presentatie van een resource wordt teruggegeven. Het is niet gedefineerd wat het content-type van deze resource is; en dat is handig. We kunnen dus allerlei verschillende gegevens in verschillende formaten uniform aanbieden.
Met REST maken we gebruik van bestaande methoden en technieken om informatie uit te wisselen. Tijd voor een klein voorbeeld. Een auto die bij een autodealer te koop staat kan via REST opgevraagd worden. Het is een Volvo met kenteken LD-85-NG. De auto is direct via een URL op te vragen, bijvoorbeeld: http://www.autodealer.nl/autos/LD-85-NG. Via een HTTP GET request krijgen we nu bijvoorbeeld in XML een beschrijving van de auto.
En nu denk ja, jamaar, dat bestaat al lang. Ik gebruik altijd dit systeem. Dat klopt, het web is RESTful. Het gebruikt namelijk URL's die naar resources van verschillende contenttypes verwijzen. We gaan dus eigelijk met REST terug naar de basis concepten van het internet. Maar ook verder, het wordt namelijk veel leuker.
Stel dat je zelf een dealer bent en je bent aangesloten bij een automarktplaats. Je wilt snel en simpel je auto's beheren. Dan zou je dat via REST en bijvoorbeeld XML kunnen doen. Indien je een nieuwe auto gaat verkopen met dan stuur je de gegevens in XML op naar http://www.autodealer.nl/autos/ via een HTTP PUT methode. Er wordt dan een nieuwe auto aangemaakt en bij autodealer.nl getoond. Wil je de prijs van de auto aanpassen dan HTTP POST je de nieuwe gegevens naar autodealer en die werkt de gegevens van de te verkopen auto bij. En als de auto verkocht is stuur je de XML naar http://www.autodealer.nl/autos/LD-85-NG met een HTTP DELETE request.
Doordat we een URL gebruiken om de gegevens op te halen, kunnen we naast verschillende content-types ook cache-haders mee sturen, en dan wordt het leuk. Middels de cache-headers kunnen we dus aangeven hoe lang de informatie van bijvoorbeeld de eerder genoemde auto geldig is. Stel dat wij een autoverkoop portal zijn en auto's van autodealer.nl uitlezen dan weten we precies wanneer we welke auto's moeten updaten. Voor kleine sites is dit overbodige luxe. Maar bij een grote site kan het cachen van gegevens, al is het maar een minuut, veel requests op de webserver schelen.
Tot zover, we gaan er op door, want ik vind dit weer bijster interessant.
Voor wie het niet kent; REST houdt in dat resources via URL's worden aangeboden en kunnen worden gemodificeerd via het HTTP. Goed dat is misschien voor de meesten mensen abracadabra, daarom een kleine uitleg. Allereerst moet ik wat vertellen over Web Services. Web Services zijn diensten die een persoon of bedrijf aanbiedt waarmee andere personen of websites iets doen. Zoals SOAP. Via SOAP koppelingen of RPC's worden gegevens opgevraagd en soms kunnen er zelfs gegevens worden weggeschreven. Meestal zijn deze methodes lelijk en ondoorzichtig voor een gebruiker.
REST is een architectuur stijl voor het maken van een webapplicatie, het defineert dus geen protocol maar een manier om met elkaar te communiceren. Een URL wordt aangeroepen en een presentatie van een resource wordt teruggegeven. Het is niet gedefineerd wat het content-type van deze resource is; en dat is handig. We kunnen dus allerlei verschillende gegevens in verschillende formaten uniform aanbieden.
Met REST maken we gebruik van bestaande methoden en technieken om informatie uit te wisselen. Tijd voor een klein voorbeeld. Een auto die bij een autodealer te koop staat kan via REST opgevraagd worden. Het is een Volvo met kenteken LD-85-NG. De auto is direct via een URL op te vragen, bijvoorbeeld: http://www.autodealer.nl/autos/LD-85-NG. Via een HTTP GET request krijgen we nu bijvoorbeeld in XML een beschrijving van de auto.
En nu denk ja, jamaar, dat bestaat al lang. Ik gebruik altijd dit systeem. Dat klopt, het web is RESTful. Het gebruikt namelijk URL's die naar resources van verschillende contenttypes verwijzen. We gaan dus eigelijk met REST terug naar de basis concepten van het internet. Maar ook verder, het wordt namelijk veel leuker.
Stel dat je zelf een dealer bent en je bent aangesloten bij een automarktplaats. Je wilt snel en simpel je auto's beheren. Dan zou je dat via REST en bijvoorbeeld XML kunnen doen. Indien je een nieuwe auto gaat verkopen met dan stuur je de gegevens in XML op naar http://www.autodealer.nl/autos/ via een HTTP PUT methode. Er wordt dan een nieuwe auto aangemaakt en bij autodealer.nl getoond. Wil je de prijs van de auto aanpassen dan HTTP POST je de nieuwe gegevens naar autodealer en die werkt de gegevens van de te verkopen auto bij. En als de auto verkocht is stuur je de XML naar http://www.autodealer.nl/autos/LD-85-NG met een HTTP DELETE request.
Doordat we een URL gebruiken om de gegevens op te halen, kunnen we naast verschillende content-types ook cache-haders mee sturen, en dan wordt het leuk. Middels de cache-headers kunnen we dus aangeven hoe lang de informatie van bijvoorbeeld de eerder genoemde auto geldig is. Stel dat wij een autoverkoop portal zijn en auto's van autodealer.nl uitlezen dan weten we precies wanneer we welke auto's moeten updaten. Voor kleine sites is dit overbodige luxe. Maar bij een grote site kan het cachen van gegevens, al is het maar een minuut, veel requests op de webserver schelen.
Tot zover, we gaan er op door, want ik vind dit weer bijster interessant.
Subscribe to:
Posts (Atom)