Separate REST JSON API server and client? [closed]

Answer 1

We use the following variant of #3: Make a JSON-only REST API server. Make an HTML website server. The HTML web server is not, as in your variant, a client to the REST API server. Instead, the two are peers. Not far below the surface, there is an internal API that provides the functionality that the two servers need.

We're not aware of any precedent, so it's kind of experimental. So far (about to enter beta), it has worked out pretty well.

Answer 2

I've gone for a hybrid approach where we user Sinatra as a base, ActiveRecord / Postgress etc to serve up page routes (slim templates) expose a REST API the web-app can use. In early development stuff like populating select options is done via helpers rendering into the slim template, but as we approach production this gets swapped out for an AJAX call to a REST API as we start to care more about page-load speeds and so forth.

Stuff that's easy to render out in Slim gets handled that way, and stuff (populating forms, receiving form POST data from jQuery.Validation's submitHandler etc, is all abviously AJAX)

Testing is an issue. Right now I'm stumped trying to pass JSON data to a Rack::Test POST test.

Answer 3

Very well asked. +1. For sure, this is future useful reference for me. Also @Aaron and others added value to discussion. Like Ruby, this question is equally applicable to other programming environments.

I have used the first two options. First one for numerous applications and second one for my open source project Cowoop

Option 1

This one is no doubt the most popular one. But I find implementation are very much http-ish. Every API's initial code goes in dealing with request object. So API code is more than pure ruby/python/other language code.

Option 2

I always loved this.

This option also implies that HTML is not runtime generated on server. This is how option 2 is different from option 3. But are build as static html using a build script. When loaded on client side these HTML would call API server as JS API client.

• Separation of concerns is great advantage. And very much to your liking (and mine) backend experts implement backend APIs, test them easily like usual language code without worrying about framework/ http request code.

• This really is not as difficult as it sounds on frontend side. Do API calls and resulting data (mostly json) is available to your client side template or MVC.

• Less server side processing. It means you may go for commodity hardware/ less expensive server.

• Easier to test layers independently, easier to generate API docs.

It does have some downsides.

• Many developers find this over engineered and hard to understand. So chances are that architecture may get criticized.

• i18n/l10n is hard. Since HTML is essentially generated build time are static, one needs multiple builds per supported language (which isn't necessarily a bad thing). But even with that you may have corner cases around l10n/i18n and need to be careful.

Option 3

Backend coding in this case must be same as second option. Most points for option 2 are applicable here as well.

Web pages are rendered runtime using server side templates. This makes i18n/l10n much easier with more established/accepted techniques. May be one less http call for some essential context needed for page rendering like user, language, currency etc. So server side processing is increased with rendering but possibly compensated by less http calls to API server.

Now that pages are server rendered on server, frontend is now more tied with programming environment. This might not be even a consideration for many applications.

Twitter case

As I understand, Twitter might does their initial page rendering on server but for page updates it still has some API calls and client side templates to manipulate DOM. So in such case you have double templates to maintain which adds some overhead and complexity. Not everyone can afford this option, unlike Twitter.

Our project Stack

I happen to use Python. I use JsonRPC 2.0 instead of REST. I suggest REST, though I like idea of JsonRPC for various reasons. I use below libraries. Somebody considering option 2/3 might find it useful.

• API Server: Python A fast web micro framework - Flask
• Frontend server: Nginx
• Client side MVC: Knockout.js
• Other relevant tools/libs:
  • Jquery
  • Accounting.js for money currency
  • Webshim : Cross browser polyfill
  • director: Client side routing
  • sphc: HTML generation

My conclusion and recommendation

Option 3!.

All said, I have used option 2 successfully but now leaning towards option 3 for some simplicity. Generating static HTML pages with build script and serving them with one of ultra fast server that specialize in serving static pages is very tempting (Option 2).

Answer 4

I'm usually going for the 2nd option, using Rails to build the API, and backbone for the JS stuff. You can even get an admin panel for free using ActiveAdmin. I've shipped tens of mobile apps with this kind of backend. However it heavily depends if your app is interactive or not.

I did a presentation on this approach at the last RubyDay.it: http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

For the third option, in order to get responsiveness of the 2nd one, you might want to try pajax as Github does.

Answer 5

I personally prefer option (3) as a solution. It's used in just about all the sites a former (household name) employer of mine has. It means that you can get some front-end devs who know all about Javascript, browser quirks and whatnot to code up your front end. They only need to know "curl xyz and you'll get some json" and off they go.

Meanwhile, your heavy-weight back-end guys can code up the Json providers. These guys don't need to think about presentation at all, and instead worry about flaky backends, timeouts, graceful error handling, database connection pools, threading, and scaling etc.

Option 3 gives you a good, solid three tier architecture. It means the stuff you spit out of the front end is SEO friendly, can be made to work with old or new browsers (and those with JS turned off), and could still be Javascript client-side templating if you want (so you could do things like handle old browsers/googlebot with static HTML, but send JS built dynamic experiences to people using the latest Chrome browser or whatever).

In all the cases I've seen Option 3, it's been a custom implementation of some PHP that isn't especially transferable between projects, let alone out in to Open Source land. I guess more recently PHP may have been replaced with Ruby/Rails, but the same sort of thing is still true.

FWIW, $current_employer could do with Option 3 in a couple of important places. I'm looking for a good Ruby framework in which to build something. I'm sure I can glue together a load of gems, but I'd prefer a single product that broadly provides a templating, 'curling', optional-authentication, optional memcache/nosql connected caching solution. There I'm failing to find anything coherent :-(

Answer 6

A very nice question and I'm surprised as I thought this is a very common task nowadays such that I will have plenty of resources for this problem, however turned out not to be true.

My thoughts are as follows: - Create some module that have the common logic between the API controllers and HTML controllers without returning json or rendering html, and include this module in both HTML controller and API controller, then do whatever you want, so for example:

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end