Now this was using a "GET" and we all know that REST scales, so what was the problem? Mr Creswell summed it up when he talked about common sense architecture. So sure REST can scale but it isn't magic. It does various things around state management that can help but it still requires basic fundamentals to be done, its not magic and its not a silver bullet for scalability.
So does the Web scale? Yes. But when Google is allegedly the 4th largest server manufacturer in the world, maybe its not REST but hard work and brains and an awful lot of hardware....
Technorati Tags: REST
5 comments:
Except of course that WS-* can scale.
When people state "REST scales" this isn't actually true its more "REST enables horizontal application scaling pretty well", horizontal of course is only one option when it comes to scaling.
"we can say "REST can scale" while "WS-* can't""
Urgh I find that quite hard to reason about.
Scale how much on what axis? Are we takling straight server scaling or the number of platforms/developers/langugages that can create mashups easily.
Further REST is an "architectural style" and WS-* is surely a bunch of specs or a technology stack. Isn't this an apples and oranges comparison?
Dan.
http://www.dancres.org/blitzblog
You're not really using a $5 hosting plan as a fundamental argument for the non-scalability of REST.
Are you?
I am intrigued at why you suggest that WS-* will scale up and REST will not when surely the bottlenecks are the same for both approaches? Any more info or evidence to suggest why you think this is the case?
Of course REST can be made to scale (as can WS-*), the point I was making is that you have to make it scale in the same way as people make non-REST systems scale. There can be arguments over which is easiest to scale but its important to remember that "Just using REST" will not give you the reliability and scalability of Google.
Scaling takes brains, with or without REST.
By default, The only cacheable HTTP method on the web is GET. WS-* doesn't use GET, it throttles everything through POST, which intermediaries like proxies and such, doesn't cache. Using GET in your application gives you this scalability for free.
It of course requires you to have a backend that can handle the load, but it's at least possible for every box on every hop between your users and your server to offload some of that load, something that is impossible with WS-* and POST.
On top of the server handling the load, the application has to be written in such a way that it enables the intermediaries to cache; storing everything as static HTML files on a modern web server would normally do. If you want more dynamic behaviour and logic stuffed in, you'll need to read up on ETags, Last-Modified, If-Modified-Since, If-None-Match, etc. However, this is not any more difficult than what you would need to do in a WS-* architecture to reap the same benefits. Plus, your application would be a lot less usable for anything but SOAP-speaking clients.
Post a Comment