Separate REST JSON API server and client?
I'm about to create a bunch of web apps from scratch. (See http://50pop.com/code for overview.) I'd like for them to be able to be accessed from many different clients: front-end websites, smartphone apps, backend webservices, etc. So I really want a JSON REST API for each one.
Also, I prefer working on the back-end, so I daydream of me keeping my focus purely on the API, and hiring someone else to make the front-end UI, whether a website, iPhone, Android, or other app.
Please help me decide which approach I should take:
TOGETHER IN RAILS
Make a very standard Rails web-app. In the controller, do the respond_with switch, to serve either JSON or HTML. The JSON response is then my API.
Pro: Lots of precedent. Great standards & many examples of doing things this way.
Con: Don't necessarily want API to be same as web app. Don't like if/then respond_with switch approach. Mixing two very different things (UI + API).
REST SERVER + JAVASCRIPT-HEAVY CLIENT
Make a JSON-only REST API server. Use Backbone or Ember.js for client-side JavaScript to access API directly, displaying templates in browser.
Pro: I love the separation of API & client. Smart people say this is the way to go. Great in theory. Seems cutting-edge and exciting.
Con: Not much precedent. Not many examples of this done well. Public examples (twitter.com) feel sluggish & are even switching away from this approach.
REST SERVER + SERVER-SIDE HTML CLIENT
Make a JSON-only REST API server. Make a basic HTML website client, that accesses the REST API only. Less client-side JavaScript.
Pro: I love the separation of API & client. But serving plain HTML5 is quite foolproof & not client-intensive.
Con: Not much precedent. Not many examples of this done well. Frameworks don't support this as well. Not sure how to approach it.
Especially looking for advice from experience, not just in-theory.
Answer
At Boundless, we've gone deep with option #2 and rolled it out to thousands of students. Our server is a JSON REST API (Scala + MongoDB), and all of our client code is served straight out of CloudFront (ie: www.boundless.com is just an alias for CloudFront).
Pros:
- Cutting-edge/exciting
- A lot of bang for your buck: API gives you basis for your own web client, mobile clients, 3rd party access, etc.
- exceedingly fast site loading / page transitions
Cons:
- Not SEO friendly/ready without a lot more work.
- Requires top-notch web front-end folk who are ready to cope w/ the reality of a site experience that is 70% javascript and what that means.
I do think this is the future of all web-apps.
Some thoughts for the web front end folks (which is where all the new-ness/challenge is given this architecture):
- CoffeeScript. Much easier to produce high-quality code.
- Backbone. Great way to organize your logic, and active community.
- HAMLC. Haml + CoffeeScript templates => JS.
- SASS
We've built a harness for our front-end development called 'Spar' (Single Page App Rocketship) which is effectively the asset pipeline from Rails tuned for single page app development. We'll be open-sourcing within the next couple of weeks on our github page, along with a blog post explaining how to use it and overall architecture in greater detail.
UPDATE:
With respect to people's concerns with Backbone, I think they are over-rated. Backbone is far more an organizational principle than it is a deep framework. Twitter's site itself is a giant beast of Javascript covering every corner-case across millions of users & legacy browsers, while loading tweets real-time, garbage collect, display lots of multimedia, etc. Of all the 'pure' js sites I've seen, Twitter is the odd one out. There have been many impressively complicated apps delivered via JS that fare very well.
And your choice of architecture depends entirely on your goals. If you are looking for the fastest way to support multiple clients and have access to good front-end talent, investing in a standalone API is a great way to go.