is well known and established archetecture. It does not need our approvals or
It's something different that we want to express. We'd like to thank all those
people who formulated those ideas.
While one can argue that REST has "always" existed along with the web, from
our experience we can see that most of web applications we have created up to
the late 200x were stateful.
We can see that many web applications should support the application (session)
state. And here REST has given a rule:
client stores a session state;
server does not store a session, and is represented as set of services;
if there is a state that cannot be stored on a client (e.g. due to security
reasons), then server should use caches, and be able to reconstruct that state
upon cache miss.
Now is a good time for the proliferation of the REST, as even weakest clients
(browsers) can implement its requirements.
REST allowed us to drastically simplify development and support, to unload
server, and to build better web applications.
We compare web applications we have written a decade ago using ASP.NET, and in
last 3-4 years using RESTful ideas both in java and in .NET. Clearly, the later
have better performance, but from the support standpoint the most appealing is
that you can instantly upgrade the application without impacting users, as there
are no sessions on the server. For the same reason you should not puzzle over
whether you should use in-process sessions and session stickness with load
balancing server, or out-of-process sessions.
Things became simpler:
server now is pure logic through services (WCF, Web API, JAX-RS);
client is gui - jquery, kendoui or other;
aspx/jsf pages gone completely;
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u