Thinking about RESTful dynamic web applications
posted: April 29th, 2006 · by: Sven
I signed up to the REST Discussion Mailing List a while ago and greatly enjoyed to lurk the really interesting and instructive discussions over there - I learned a big deal from it about my own projects (both past and future ones) from following that.
And yes, it really makes sense to me to better respect HTTP and build more RESTful applications - at the very least when it comes to higher scalability through better caching.
But … having most oftenly been involved in projects where there are highly dynamic and customized pages (think: www.yahoo.com or worse) this seems to be more or less an unsolved problem within REST.
One approach that I came up with (well, at least: conceptually) has been mentioned by Bill Venners.
“For example, I do want to say, “Welcome, John” on the top of every page
once you’ve signed in. But I’m currently planning on attempting to have only
two representations of each page, one for signed in users and one for
anonymous. The signed in representation will have some JavaScript that grabs
the Welcome greeting and insert it dynamically on the page. If a client
doesn’t have JavaScript enabled, then they still see they are signed in,
because that’s one of the two representations sent from the server, but they
won’t see their name in a welcome message. To me that’s a graceful
degradation for non-JavaScript clients that I’m willing to accept in exchange
for improved cache effectiveness. (The signed in/anonymous representations
only work for clients with cookies enabled. Otherwise I have to fall back to
URL rewriting, where the caching will be less effective, because I’ll have a
different URI per resource per session.)”
http://groups.yahoo.com/group/rest-discuss/message/5997
Leaving degradation alone for a moment - how could a Javascript snippet that “grabs the Welcom greeting” look like?
Obviously it would need to be idententical for every client accessing the ressource. We’d otherwise get different ETags and instantly loose the whole caching point. That is, we can’t include something like
<script>http://www.domain.com/user/1/welcome.js</script>
for the simple reason that it’s different from the URL any other user would be served with.
Probably I’m blind but I can’t see any other reasonable way than to use a cookie here. But aren’t cookies unRESTfully evil? Luckily there are some statements from highly respected RESTafarians ;) who declare that cookies are ok to use as long they don’t mean to store application state on the server. From my point of view there’s nothing against it.
Instead of tailoring the whole page on the server (producing uncachable pages) we’d pass the same sceleton (or “shell”) page to every client - along with a cookie that does not need to store anything else than a unique ID on the client.
Afterwards the client can pull further content (be it a simple message or full fledged “components”) from the server because she now knows how to construct the apropriate URLs:
var url = 'http://www.domain.com/user/' + cookie.userId +
'/welcome.js';
Again, welcome.js could now be cached - or (in case we’d want to get more nifty) itself be a “shell” pulling further, specialized content.
I don’t know if this is what Bill meant by “conversational state” - I’d simply call that a “session” (which has been a recent and very interesting debate on the above mentioned mailing list). The server “initializes” the client (by issuing the cookie) to use certain ressources for further lookups. This “initialization” will remain as long as the cookie remains. There’s no particular “state” to be maintained on the server.
The REST FAQ over at blueoxen.net explains it like this:
Interaction is stateless when a single request can be processed without knowing which requests have been made previously. Consider an authenticated request for a person’s phone number. You could have a conversation that goes like this:
Me: I would like your phone number, please. You: Who are you? Me: I'm your old buddy Frank, don't you recognize me? You: Oh, well then my number is...
That’s a stateful conversation because I supplied my credentials without resubmitting my request. This next conversation is stateless:
Me: I would like your phone number, please. You: Who are you? Me: I'm your old buddy Frank, and I would like your phone number please. You: Oh, well then my number is....
In our “Welcome John!” example the dialog would look like this:
Client: "Hi! I think you know me by my [username] and [password]" Server: "Year, hi again! You'll find your stuff by using the ID 1." Client: "Cool. Than please hand me over the welcome message with the ID 1." Server: "Ok, here it is: Welcome John!"
As far as I can see two issues remain. One is authorization to restricted ressources. I’d love to use the HTTP auth scheme here also. I’ve never done so because of the usual problems with it - like being nasty, not styleable, no logout etc. But on the one hand, I think this should be possible to solve with some JS/AJAX style approach. On the other hand it seems as if I’m going to be on Ruby on Rails with my next upcoming project and I don’t know about how this would actually fit together.
The other one is degradation.
Ok, as long as we’re not going to do any more than display a “Welcome back, John!” message once the user’s logged on - well, I’m sure that I’d be able to convince my customers to simply go without that for that 5 to 10% users who might Javascript have turned off.
For some projects a noscript message could do it - like:
<noscript>
Too bad! With JS turned on, you could [rule the world].
</noscript>
Another approach could have the cachability of the served pages itself depend on whether the client hast JS turned on or not - and serve a different etagged page to people without JS along with the appropriate headers to prevent these pages from being cached at all.
if client.isJsEnabled():
headers(cachable) + shell page
else:
headers(no-cache) + classical user-customized page
endif
By the way, from reading this article I think, this same issue evolves with Ruby on Rails concerning these nifty “flash” messages when using page caching.
jack said January 24th, 2011 at 03:26 PM ¶
UCVHOST has changed the face of web hosting industry in a major way, people were paying gold for peanuts (and it is still happening). cheap hosting has become synonym with UCVHOST, anybody and everybody who wants a reliable and affordable domain web hosting visits UCVHOST and gets either windows vps or Linux hosting from UCVHOST. UCVHOST sells cheap hosting WITHOUT hidden terms and conditions where as competition has huge MSA and SLA’s which are good enough to confuse a seasoned lawyer also. For clients by now Business with us for the value of windows vps became very critical piece of puzzle for their whole operation, uptime and performance became a huge concern.. However it came with a cost, dedicated servers proved to be at least 100 times expensive in comparison to any windows or Linux plans. Somewhere in the labs engineers were working on splicing raw power of a server into virtual instances, this technology was called as Virtualization also termed as or virtual private servers. Also UCVHOST comes handy when you are looking for remotely hosted and managed FOREX MetaTrader4 terminals. Our forex vps platform is all geared up in fight of pips, our platform support any number of expert advisory (EA) and along with an assure of 100% uptime. Our Virtual Forex Tradng Terminals are well equipped to help you in making money .
chat said March 31st, 2011 at 08:18 PM ¶
The following cleaned up the issue:
Dependencies.loadoncepaths -= Dependencies.loadoncepaths.select{|path| \ path =~ %r(^#{File.dirname(FILE)}) }
Okey oyunu said May 12th, 2011 at 04:25 PM ¶
Thanks a lot for this nice post. Tüm dünya artik okey oyunu oynuyor. Yillardir bir çok oyun programi olmasina ragmen, içlerinden en güzeli olarak nitelendirebilecegimiz tek bir site göze çarpmaktadir. Diger tüm okey oyunu programlarinin aksine ücretsiz olmasi ve 3 boyutlu olarak hizmet vermesi mükemmel bir gelismedir. Sizlerde www.okey-oyunu.com adresinden bu essiz okey oyununu indirebilirsiniz. Kullanimi çok basit ve Türkçe dil seçenegi ile kolaylikla oyuna baslayabilirsiniz. Ister kendi ülkenizden, isterseniz dünyanin tüm farkli bölgelerinden dilediginiz oyun odalarini seçerek, oyuna hemen baslayabilirsiniz. Okey oyunu oynamak için artik arkadas bile aramaniza gerek kalmadan, bilgisayarinizdan 100 binlerce üye ile online olarak okey oyununu oynamanin zevkine varabilirsiniz.