Today I tried to explain REST (as in REpresentational State Transfer, not near sleep) to a manager and why some of the services deployed at the organization he was working for wasn't REST. While there isn't a formalized spec, there is a dissertation by the Roy Fielding, who came up with the REST-principles as a set of principles that guided him while shaping the HTTP 1.1 standard which only recently got a successor with version 2.0… REST is a set of principles/guidelines that are very stable & predictable. It is also very simple, and theirin lies both its strength, and the sometimes too loose application of its principles.
Apparently many developers didn't get 'the web' (HTTP) right, hence REST was developed as a basic set of principles to explain how HTTP is supposed to work. This is a list of my favourite parts, also based on some secondary resources.
Some key concepts.
Sometimes I get a bit upset about a state a project I get to work on is in. Recently I came across a project which frontend served over 30 files that could be reduced easily to about 10. I got upset because to me it is like one of the basic things you have to be aware of as a web developer. I told the others working on the project that is a problem that should be fixed, to optimize speed. But later that day, in bed, I started wondering because the pages were served using HTTPS: was I actually correctin stating it as a problem? Well, currently still yes.
I started wondering because I remembered something about 'pipe-lining'. A year ago I turned on the experimental SPDY protocol a year ago, which supports asynchronous pipe-lining. Pipe-lining allows browsers to request all files in one request, which diminishes the reason why a developer should try to reduce the numbers of file…
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .