I’m currently exploring the different options for building a not-too-complex web application, in which some role based access control is involved. Furthermore, read/write operations on a small number (think around 5) of different database tables must be performed.
I’ve been toying with the idea of creating a JSON-based API, in which one or several PHP files serve as a layer on top of the database. The webapp itself would be completely ‘static’ HTML and javascript, using XHR to retrieve data from the server and, eventually, write stuff back to it. An example would be the current Twitter homepage – when viewing a user’s timeline, no tweets are actually passed in the initial HTML: it’s all being fetched by some nifty javascript.
One important downside that I see to this, is that the Googlebot would have a hard time indexing this kind of website. Several components of the app should function like regular, published content, which can appear in Google search results without trouble. How does, for example, Twitter, achieve this? Do they serve up a different page when their servers are approached by web crawlers?
Also, I’d like to hear some thoughts on this concept… to me, it seems a very interesting and clean way of separating business logic from presentation, but, as always, I could be horribly wrong 🙂
Well, it’s a global question that will require a big answer 🙂
First of all, about your Twitter question, they use hashbang uri style.
When you go to twitter.com/cx42net for example, you are automatically redirected to twitter.com/#!/cx42net.
When it’s a crawler, like Google bots, the crawler will change
#!by?_escaped_fragment=.For twitter, it would result as: http://twitter.com/?_escaped_fragment=/cx42net.
I won’t go deeper in the details, in order to avoid telling mistakes, a good link is well preferred, so here we go : SEOMoz: How To: Allow Google to Crawl your AJAX Content
Now, for your web app in RESTful, I really like the idea of separating the client from the server and I try to work like that too.
You are talking about Role Based Access, which mean you will have to identify your users in order to allow/deny access to certain part of your api.
There is two schools on how to authenticate users on an API :
The former is very simple to implement but I would suggest you to do it through HTTPS since the password is sent in clear through the network.
The later is great but way more complex to implement.
But in fact, it could be perfectly what you are looking for, because despite authenticating your user, you can give them access to certain part of your API and restrict them on some other part. An common example is how Facebook/Twitter work for that, and I’m sure you already have allowed Third Party apps to use your Twitter/Facebook account.
Now, using OAuth will generally impose you to have a login/password table stored in your database. You can use OpenID, but this start more as an headache than simplifying your users:
you have to authenticate them from the OpenId provider (like Google), then redirect to your API for allowing access (if it’s the first time), THEN redirect your user to your application.
Finally, I’ll quote Fred Wilson, the 10 Golden Principles of Successful Web App are:
Well, that will do for now, if I have any other idea, I’ll edit the answer and add a comment.