7 looks a lot like 5 actually. You could say it's already happening in Cloud gaming (Gaikai, OnLive), but for general purpose application I think we need to have either:

- new types of (underpowered) devices: body augmentation?

- or much larger UI and processing needs: Photo filtering is more and more back in the client... video processing a-la Animoto? Siri? 3D UIs so favored in SF?

Where did AJAX apps go? If you ask me these are thick clients. The funny thing is that HTTP explicitly omitted AJAX in order to acheive linkability and thin clients. With AJAX linkability got thrown out the window and the clients just keep getting fatter. No wonder that the server gets a less important role. I hope that people understand that they are breaking REST when they bild these type of apps.

How are they breaking REST? What does the method of consumption (e.g. AJAX enhanced pages vs single page apps) have to do with restful API design... at all?

edit: also possible I misunderstand your statements

I was talking about REST websites, A.K.A web 1.0 websites.

What do I mean? Well, a 1.0 website generally follows REST. REST means representational state transfer, which means that each application state should have a representation on the server. Another way of expressing this is that each possible state on the website should have an URL. No more "go to example.com and click X, then Y then scroll then Z". Instead, every possible state has a link, so you just give the link. HTTP was designed to enforce linkability.

Enter AJAX. Suddenly the server is out of control. You can now deviate from the linkability principle, and a lot of apps do.

When the linkability constraint is lifted, the client state is allowed to deviate from the server state. This gives less responsibility to the server. No wonder that it gets less to do.

That is what I meant.

You can still use a REST API from a web 2.0 website, that is another question. But a web 2.0 webpage plus an REST API to fetch data makes the total app non-REST (at least if you don't actively try to make it such).

No, I think you're right. I'm pretty sure strictfp is misunderstanding REST.

TO answer your question (though it may have been rhetorical), the way the client consumes the service has no bearing on whether or not it is RESTful.

7. html5 or mozilla gecko type of app stores? or any other alternatives?

You missed the round of 'apps that are local on your machine and the data is local on your machine so you better have a backup'. That is the part we are escaping from now.

Straight to the part where:

1) The service is free, so if you're data gets lost, you're out of luck.

2) The government just has to ask nicely to look at the data without a court order.

3) Your data becomes the property of the 3rd party whose service you are using.

It seems like the ideal scenario is:

1) Your data is stored, encrypted by you, in the cloud

2) In a standards-based service which you pay for

3) And federated to other services by you

Mozilla Weave was an instance of a narrow application of this:

http://mozillalabs.com/blog/2007/12/introducing-weave/

There is still the issue that once you grant access to a third party you can't revoke it, but that's unsolvable through technical means in somewhat the same way DRM is unsolvable.