I've tried to accomplish a REST API + JS client on a few of my projects, but where I get hung up is session handling.
What I've ended up doing is writing the REST backend and writing the presentation layer in something light, like flask or sinatra, just for session handling.
you shouldn't need to do session handling if you are going REST. Rest is all about not having state. If you need authentication, authenticate on every request. If your request needs some additional info to give a response, pass that information in when sending the request.
It's really a different paradigm and sometimes it can get really painful to move away from the way of thinking that we are used to.
I realize that you don't want to maintain state in a REST api. It's not that it's painful to do something I'm use too (ie: session handling), it's just its painful implementing.
My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.
(3) Every request goes through a proxy written in Ruby/EventMachine which either just passes through the request to the backend server if requesting something public or first checks that the client's auth cookie is valid if its requesting protected resources.
This certainly isn't as simple as it would be in a server-side framework, but otherwise it works pretty well.
I agree, this does appear to be the trend. Google also has indexing support for AJAX pages (http://code.google.com/web/ajaxcrawling/index.html) so it's not hard to make a single-page app that is indexable by Google. My concern is that we are building all of this on top of HTTP, which wasn't really meant to be used this way, and there's bound to be some caveats from that. One potential pitfall I can think of is cookie management - the JavaScript APIs to manipulate cookies is very poorly defined easy to make mistakes while using. I think this is doable but we need to tread softly to make sure that we don't introduce new classes of vulnerabilities.
"My concern is that we are building all of this on top of HTTP, which wasn't really meant to be used this way, and there's bound to be some caveats from that". Can you ( or anybody ) expand on this ?
This whole separation of UI and domain is the kind of Ivory Tower academic nonsense perpetuated by the DDD folks and many, many others.
Nowhere is this virulent plague more endemic than in the Java world. As the joke goes, the Java programmer's response to any problem is to add just one more layer of abstraction.
And I say this as a Java programmer of some 10+ years experience so please don't take it as mindless Java bashing.
As Joel (the classic Joel of old) would say: all abstractions are leaky. To add my own editorial: the less hand-wringing and self-flagellation about the purity of the uberlanguage, uberframework or uberarchitecture, the better.
Model-UI separation is a pretty basic principle that decent programmers put into practice every day. I find it tends to aid the design process rather than obstruct it.
Separating the domain from the UI is just common sense and good business practice. Having the two melded is probably the most common way for companies to get stuck using an old application. Their business logic (the real value) is stuck in a glob of UI outdated code (which no one cares about anymore).
I say this as a Smalltalk programmer of 10+ years experience. Unfortunately, it's often been the worst Smalltalk apps that have had the longest life. In those cases, it's just too horrible to migrate to a different environment, and the rate of change in the current application makes the opportunity cost of freezing ongoing development too painful. The result is often one or two failed Java projects seeking to replace the Smalltalk app, which continues to creak along beyond all expectations. Often, the apps with the good architectures got replaced quickly.
I think a lot of that could be fixed with automated translation to Groovy and some custom UI frameworks.
No, they are not becoming irrelevant. Frameworks add significant value on the front end as well -- the easiest example is templating, which is a) not natively supported in HTML b) hard to fake with CSS/Javascript and c) virtually required for productivity, consistency, and maintainability.
I suppose one could theoretically fake this by using a script to spit out static HTML served by Apache, but then the combination of Apache and your script is morally equivalent to a server-side web framework.
I don't really get it either, but one reason I can think of is that it saves some bandwidth because sending the data that gets inserted into the template will probably be smaller than the HTML after templating.
That seems counter intuitive to me. With JS templating, you are sending all the page structure, data, and markers as to how to insert the data into the structure. Without, you are just sending the structure and data. Assuming you are gzipping the output in both cases, which would eliminate the bandwidth of the duplicated structure items, wouldn't the JS templating naturally be longer?
Here is a contrived example, that shows the pros and cons of each, as I see them. Pretend you have an 'link' object in JavaScript and you want to generate the view for that link using templating:
var link = { url: 'http://news.ycombinator.com, title: 'Hacker News' , extraStuff: someBigObject };
* Pros: if you have to generate 100 links, you only passed down the template div once. Also, if the extraStuff property is really large, there is no bandwidth spent on sending it up, since it runs on the page
* Cons: if you generate 0 links, you still passed down the template div once. If you have this view defined also in a server side template, you have duplicated view logic (really annoying).
With server side templating:
$.load('url/to/template', link);
* Pros: If you generate 0 links, no extra data is sent or received. Also, your view logic is all in one place (on the server).
* Cons: If you generate 100 links, there are 100 extra HTTP requests, and you have to deal with timeouts, loading indicators, etc.
The difference is that with server rendered templates you're sending the structure multiple times. For example if you're displaying a list of things, you have a list of n times structure + n times data. If you do it at the client side you have 1 times structure + n times data.
Say you have a site that uses a lot of AJAX to make similar calls. Say for instance send message, recieve message. Instead of sending the entire message formatting and all back and forth you send json objects and bind them to jquery templates.
I don't think that it is useful for a standard site, one that needs to be indexed by search engines and needs all of it's content to be available on page load. I have made use of it in single page web applications before, though.
It completely blows hand generation of HTML out of the water for maintainability. You can keep your templates inside of the HTML page using a <script> element with a special type, and keeps a lot of that view logic out of your JavaScript. It also provides a nice alternative to using a hidden element and cloning it, then switching attributes, text, and values.
I don't know for the life of me why you would use either for static templating, use a CMS that publishes flat HTML files to your server farm. It reduces a lot of run-time dependencies and requirements and makes them compile-time concerns. Which as a general rule of thumb is better. For the dynamic stuff well that is where you draw your line server or client. I have become a convinced fan of the client.
uh, if you stop working with server side frameworks, how do you serve information to the front end javascript framework? do you intend to just expose your database to the end user's browser?
You've then just moved all data processing to the front-end, and the MVC framework moves into the client. You are then charging the consumer a tax for the processing and battery power of a presentation that could have been served with an infrastructure designed to handle it.
Moving UI to the client does nothing but move the UI to the client - it still has to be done and Javascript performance varies too much for this to be the catch-all option right now.
It's about moving the generation of HTML to the client. The concept of rendering the UI (using HTML) on the server was a step backward right from the beginning of the WWW. Servers are simply not needed to construct HTML.
I predict within a few years everyone will agree that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete. There will be a great normalization of server-side frameworks -- Ruby, PHP, Java, will essentially only be for shuffling data from your database to your client. The way it should have been all along.
The point I was trying to make was that on mobile devices where computing power and battery power is a limited resource, not only will it be running significantly more Javascript, but it would also have to render the view - effectively doubling the number of client-side tasks.
If all the device had to do was consume HTML and render it, it would impact performance and battery life less. Also, if you build your entire page in Javascript, you could see as much as 50% difference in page load performance across browsers. Until most users that still browse with IE are on a version that is at least as fast as Firefox, you're allowing client experience to vary wildly outside of your control. Basically, you control how you serve your content, but you have no control over how fast the client builds HTML from server-data. In 5 years this may not be an issue, but right now it is.
The more work you do on your own infrastructure, the more stable your service would become.
Now, I'm still a fan of single-page apps, but for initial page loads it still makes sense from a performance perspective to render it on the server.
Go and have a look at, say, Sammy. There is not a lot of heavy duty stuff gong on in JS-land. Particularly on a phone, the amount of JS required is tiny; certainly not enough to impact power consumption unless one is completely incompetent.
Also, try phonegap or jquerymobile. Tons of functionality that is immediate and battery friendly.
You _can_ do this stuff badly, but that's not what we're talking about here.
that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete
One thing often overlooked with these is that they lock your application away into islands of incompatibility. If you decide to port from one technology to another you have to go through a tedious process of porting these non compatible technologies. With a front end built entirely in JS, CSS and HTML you bring you UI back to a common technology base that can easily move from technical selection to technical selection.
Even if single-page AJAX becomes the standard for web apps, I don't see apps ever becoming the exclusive form of content on the web. It will always be mostly passive text, images, video, audio, etc. for which the thin client model is perfectly suited.
It might be very tempting to just use a REST API and a JS client for your web application. With the _escaped_fragment_ technique, you can even get indexed by Google (I'm not sure whether the other search engines already do this, but Google still is good for 90% of my search referrals, so it's ok for me).
The architecture is very clean. And you get a full third-party API "for free" instead of having to bolt it on afterwards (and maybe missing some stuff that can only be done in the web client).
Not only that, by the statelessness of REST you get really good scalability: Each request is independent of each other request, so you should be able to just add frontend- and backend-servers as you see fit without having to worry about global state.
Still, after having done just that (build a web application that is nothing but a JS frontend to a REST API - quite like the new twitter) with http://tempalias.com (source is available), I can tell you that it's not all rainbows and unicorns to misuse that saying once more.
One thing is Sammy, the client-side framework I used. It's quite easy to get lost in one big heap of application that's very hard to maintain. That is totally my mistake though and with a bit of additional experience and some help of require.js or something, I could fix that.
The other thing is UI. People are still used to the browsers page-loading-paradigm. In that case, the browsers themselves provide status update during requests. With AJAX, you'll have to do your own loading indicators and every site does it differently and no site as fine-grained as browsers (Connected, Waiting for reply, Loading... etc).
While the granularity of notifications can be fixed (best is to leave it as a single notification, but respond really quickly), you still don't solve the problem that it looks different on every site. This is a general problem of pure-AJAX sites.
Newtwitter suffers from this. Lately it's quite slow for me and I'm constantly wondering whether some JS has crashed or whether it is just slow.
And finally, sometimes, you have to do really convoluted solutions for problems which could ever-so-easily be solved by just being able to send a few dynamically generated bytes.
Of course, you could cave in and chose the impure solution, but I didn't want to which caused me some headache in my case, like not having access to the hostname of the <script src>'d bookmarklet runner script (https://github.com/pilif/tempalias/blob/master/public/bookma...) which I now have to pass in on bookmarklet invocation.
To be honest though, over time, we'll learn to cope with such issues (and browsers might get a bit better in notifying users about AJAX connections going on) and at that point the advantages could really get into play.
After tempalias which was a personal fun-project, we decided to reuse this rest-only architecture for a project my company is currently working on, fully prepared to deal with the issues outlined here because, really, we believe that the benefits might well outweigh the issues.
It's quite easy to get lost in one big heap of application that's very hard to maintain
A lot of the issues that you outlines can be dealt with by proper toolkit selection. It sounds to me that you have outgrown the jQuery (and other small rapid to develop in toolkits) and need something more robust. As it sits there are really only two players in the top end game and they are Ext and Dojo. Of the two I prefer Dojo for a host of reasons. But almost everything you have outlined are covered by both toolkits. If you are trying to build full on web apps the smaller toolkits are not a good choice as you are continually having to bolt on features. Whereas the larger toolkits have application architecture built into them.
Right, I mentioned BackBone in one of my other posts. You can bold on what you need to jQuery via some supporting projects, but many of the supporting projects are not at the maturity level of some of the larger toolkits. I do like BackBone but prefer to use Dojo's approach when it comes to large apps. jQuery can still be utilized with Dojo as well, where dojo provides all of the application architecture services and jQuery provides the UI services.
It's probably just a question of server-side frameworks being more mature at this point in time, and client-side logic being a more fertile ground for innovation due to longstanding cross-platform roadblocks. A client-server architecture is always a balancing act, and it's just teetering a bit towards the client side at the moment.
The future is being able to divide work arbitrarily between front-end and back-end depending on the particular needs of your application.
I think yes, serverside web frameworks may be becoming less relevant, to a certain extent; I just finished a monitoring app for a small company that is entirely in JS, with data stored on the server and computations (graphs, etc.) done on the fly by the client (it's an internal business app, so I get to tell end users what browser to use, etc.)
- - -
A counter argument is that it's considered "better" to bring the computation to the data than the data to the computation: ie, make the server calculate everything and serve it to a dumb client, because:
1) the server is more powerful than the client
2) one never knows what the client is capable of (the developers don't control the clients), there are many clients and just one server
3) usually, any given calculation only uses part of the data, so if the server computes and sends the results, it makes for smaller data transfers
There is however a big counter-counter-argument: I pay for the server, you pay for the client. When there are many clients that ask for results that are not easily cacheable, I think it can be much simpler to just have a dumb server that serves data, and compute on the client.
I haven't used a server side framework (other than a few CouchDB server-side JavaScript features) for years.
The biggest reason given for keeping a server side component around is that you need some way to serve up data to the UI. So until people converge on RESTful data stores there will continue to be a place for application-specific server side code.
If smartphones keep getting faster cpu's , then it is there is no problem to process data on the client, and use the server just as a dumb data spitter.
This trend will be the death of the open content web. Almost nobody out there has the diligence to maintain a standard, documented API when they have the alternative of changing their own client-side code at whim (and breaking any code anyone else may have written). In some ways Lisp was wrong about "code is data"--data is far easier to analyze and repurpose, so obfuscating it behind code is a step backwards.
This is an interesting question. If we really do get that separation of UI, then I think web-based frameworks that are heavily based on MVC+ORM will change dramatically...
The author does mention Rails as one of the server-side frameworks... but RESTful services are incredibly easy to do with rails. You don't have to use the view tier at all to use rails - you can instruct the controllers to simply provide a RESTful interface to the controller methods and then go off and build whatever separate UI you please... so I could easily still see myself using Rails even if I don't need a view tier (for the moment, this is what I'd do if I had to build a RESTful interface and I didn't have to use Java...).
On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2.
On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2.
I have used all of them and I prefer by far the JAX-RS frameworks like Jersey. They are lightweight but provide a lot of power when developing REST services in Java.
Some big wins for doing client side UI in webapps:
1. Less latency for the user when navigating the app. Data only updated from REST services as needed. Update when user looks at something else. Tons of optimizations possible.
2. Available offline (Cache manifest). Webapp useable even when 3G signal is lost.
3. Mobile app using PhoneGap with the same code base. Just drop the index.html and js/css files into the www folder.
4. UI can be developed and run from disk, with file:// protocol, no web server needed. No build or network copy step, just open/reload directly from project dir.
CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense.
CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense.
I can't agree more, we have wasted 15 years trying to hide our heads from that truth but the reality is it produces a superior experience and it is a easier development strategy. We consistently produce better applications on shorter development cycles with JS based UI apps.
Point being, if your AJAX app is built in the typical fashion, it is very unlikely to be at all RESTful itself. It is however enjoying the many benefits of being built on top of a RESTful protocol (HTML), like running in any standard web browser without any pre-deployed client software.
No they cannot be. All the complex processing cannot go to web. The web has to be light weight. Then there are messaging systems and other systems with which integration has to happen
I don't think that server side frameworks will become irrelevant. There is still a lot of value they add between the database and the HTTP interface. The part that will become irrelevant is the servlet/ASP/JSP/ERB and similar view-layers, where page-rendering policy is executed on the server. With more & more clients getting ever more powerful processors (including iPhone, Blackberry, Palm and Android), the client can do the job of executing the page-rendering policy.
This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS).
Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers).
The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.
48 comments
[ 74.0 ms ] story [ 2113 ms ] threadWhat I've ended up doing is writing the REST backend and writing the presentation layer in something light, like flask or sinatra, just for session handling.
It's really a different paradigm and sometimes it can get really painful to move away from the way of thinking that we are used to.
My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.
(1) Client sends auth info to backend server
(2) Server sets auth cookie on client
(3) Every request goes through a proxy written in Ruby/EventMachine which either just passes through the request to the backend server if requesting something public or first checks that the client's auth cookie is valid if its requesting protected resources.
This certainly isn't as simple as it would be in a server-side framework, but otherwise it works pretty well.
Nowhere is this virulent plague more endemic than in the Java world. As the joke goes, the Java programmer's response to any problem is to add just one more layer of abstraction.
And I say this as a Java programmer of some 10+ years experience so please don't take it as mindless Java bashing.
As Joel (the classic Joel of old) would say: all abstractions are leaky. To add my own editorial: the less hand-wringing and self-flagellation about the purity of the uberlanguage, uberframework or uberarchitecture, the better.
I say this as a Smalltalk programmer of 10+ years experience. Unfortunately, it's often been the worst Smalltalk apps that have had the longest life. In those cases, it's just too horrible to migrate to a different environment, and the rate of change in the current application makes the opportunity cost of freezing ongoing development too painful. The result is often one or two failed Java projects seeking to replace the Smalltalk app, which continues to creak along beyond all expectations. Often, the apps with the good architectures got replaced quickly.
I think a lot of that could be fixed with automated translation to Groovy and some custom UI frameworks.
I suppose one could theoretically fake this by using a script to spit out static HTML served by Apache, but then the combination of Apache and your script is morally equivalent to a server-side web framework.
Session management. Cookies. Sitewide functionality. Asset packing. SSL. Debugging/development tools. Tests. etc, etc, etc, etc
I can imagine that's not so good for search engines.
* Cons: if you generate 0 links, you still passed down the template div once. If you have this view defined also in a server side template, you have duplicated view logic (really annoying).
With server side templating:
* Pros: If you generate 0 links, no extra data is sent or received. Also, your view logic is all in one place (on the server).* Cons: If you generate 100 links, there are 100 extra HTTP requests, and you have to deal with timeouts, loading indicators, etc.
Seriously, the whole concept he was trying to convey just whooshed over your head so loudly that I could hear it from my home in Maine.
It completely blows hand generation of HTML out of the water for maintainability. You can keep your templates inside of the HTML page using a <script> element with a special type, and keeps a lot of that view logic out of your JavaScript. It also provides a nice alternative to using a hidden element and cloning it, then switching attributes, text, and values.
Moving UI to the client does nothing but move the UI to the client - it still has to be done and Javascript performance varies too much for this to be the catch-all option right now.
I predict within a few years everyone will agree that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete. There will be a great normalization of server-side frameworks -- Ruby, PHP, Java, will essentially only be for shuffling data from your database to your client. The way it should have been all along.
If all the device had to do was consume HTML and render it, it would impact performance and battery life less. Also, if you build your entire page in Javascript, you could see as much as 50% difference in page load performance across browsers. Until most users that still browse with IE are on a version that is at least as fast as Firefox, you're allowing client experience to vary wildly outside of your control. Basically, you control how you serve your content, but you have no control over how fast the client builds HTML from server-data. In 5 years this may not be an issue, but right now it is.
The more work you do on your own infrastructure, the more stable your service would become.
Now, I'm still a fan of single-page apps, but for initial page loads it still makes sense from a performance perspective to render it on the server.
Also, try phonegap or jquerymobile. Tons of functionality that is immediate and battery friendly.
You _can_ do this stuff badly, but that's not what we're talking about here.
One thing often overlooked with these is that they lock your application away into islands of incompatibility. If you decide to port from one technology to another you have to go through a tedious process of porting these non compatible technologies. With a front end built entirely in JS, CSS and HTML you bring you UI back to a common technology base that can easily move from technical selection to technical selection.
The architecture is very clean. And you get a full third-party API "for free" instead of having to bolt it on afterwards (and maybe missing some stuff that can only be done in the web client).
Not only that, by the statelessness of REST you get really good scalability: Each request is independent of each other request, so you should be able to just add frontend- and backend-servers as you see fit without having to worry about global state.
Still, after having done just that (build a web application that is nothing but a JS frontend to a REST API - quite like the new twitter) with http://tempalias.com (source is available), I can tell you that it's not all rainbows and unicorns to misuse that saying once more.
One thing is Sammy, the client-side framework I used. It's quite easy to get lost in one big heap of application that's very hard to maintain. That is totally my mistake though and with a bit of additional experience and some help of require.js or something, I could fix that.
The other thing is UI. People are still used to the browsers page-loading-paradigm. In that case, the browsers themselves provide status update during requests. With AJAX, you'll have to do your own loading indicators and every site does it differently and no site as fine-grained as browsers (Connected, Waiting for reply, Loading... etc).
While the granularity of notifications can be fixed (best is to leave it as a single notification, but respond really quickly), you still don't solve the problem that it looks different on every site. This is a general problem of pure-AJAX sites.
Newtwitter suffers from this. Lately it's quite slow for me and I'm constantly wondering whether some JS has crashed or whether it is just slow.
And finally, sometimes, you have to do really convoluted solutions for problems which could ever-so-easily be solved by just being able to send a few dynamically generated bytes.
Of course, you could cave in and chose the impure solution, but I didn't want to which caused me some headache in my case, like not having access to the hostname of the <script src>'d bookmarklet runner script (https://github.com/pilif/tempalias/blob/master/public/bookma...) which I now have to pass in on bookmarklet invocation.
To be honest though, over time, we'll learn to cope with such issues (and browsers might get a bit better in notifying users about AJAX connections going on) and at that point the advantages could really get into play.
After tempalias which was a personal fun-project, we decided to reuse this rest-only architecture for a project my company is currently working on, fully prepared to deal with the issues outlined here because, really, we believe that the benefits might well outweigh the issues.
A lot of the issues that you outlines can be dealt with by proper toolkit selection. It sounds to me that you have outgrown the jQuery (and other small rapid to develop in toolkits) and need something more robust. As it sits there are really only two players in the top end game and they are Ext and Dojo. Of the two I prefer Dojo for a host of reasons. But almost everything you have outlined are covered by both toolkits. If you are trying to build full on web apps the smaller toolkits are not a good choice as you are continually having to bolt on features. Whereas the larger toolkits have application architecture built into them.
The future is being able to divide work arbitrarily between front-end and back-end depending on the particular needs of your application.
- - -
A counter argument is that it's considered "better" to bring the computation to the data than the data to the computation: ie, make the server calculate everything and serve it to a dumb client, because:
1) the server is more powerful than the client
2) one never knows what the client is capable of (the developers don't control the clients), there are many clients and just one server
3) usually, any given calculation only uses part of the data, so if the server computes and sends the results, it makes for smaller data transfers
There is however a big counter-counter-argument: I pay for the server, you pay for the client. When there are many clients that ask for results that are not easily cacheable, I think it can be much simpler to just have a dumb server that serves data, and compute on the client.
The biggest reason given for keeping a server side component around is that you need some way to serve up data to the UI. So until people converge on RESTful data stores there will continue to be a place for application-specific server side code.
The author does mention Rails as one of the server-side frameworks... but RESTful services are incredibly easy to do with rails. You don't have to use the view tier at all to use rails - you can instruct the controllers to simply provide a RESTful interface to the controller methods and then go off and build whatever separate UI you please... so I could easily still see myself using Rails even if I don't need a view tier (for the moment, this is what I'd do if I had to build a RESTful interface and I didn't have to use Java...).
On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2.
I have used all of them and I prefer by far the JAX-RS frameworks like Jersey. They are lightweight but provide a lot of power when developing REST services in Java.
1. Less latency for the user when navigating the app. Data only updated from REST services as needed. Update when user looks at something else. Tons of optimizations possible.
2. Available offline (Cache manifest). Webapp useable even when 3G signal is lost.
3. Mobile app using PhoneGap with the same code base. Just drop the index.html and js/css files into the www folder.
4. UI can be developed and run from disk, with file:// protocol, no web server needed. No build or network copy step, just open/reload directly from project dir.
CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense.
I can't agree more, we have wasted 15 years trying to hide our heads from that truth but the reality is it produces a superior experience and it is a easier development strategy. We consistently produce better applications on shorter development cycles with JS based UI apps.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Point being, if your AJAX app is built in the typical fashion, it is very unlikely to be at all RESTful itself. It is however enjoying the many benefits of being built on top of a RESTful protocol (HTML), like running in any standard web browser without any pre-deployed client software.
This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS).
Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers).
The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.