Client server architecture in RESTful web applications

Question

I will like some clarification about how client server architecture should work for a modern web app with a RESTful back-end.

In a web application, the client is the browser, the server is the web server. Programmatically, we have client-side code(view), server-side code(controller/model) and database. Is my understanding correct?

So now when client-side code sends a request to RESTful server-side code, server should return a JSON/XML object rather than just simple output, correct?

If client-side code is not allowed to use any server side code to reload the web page, then how will it parse the JSON/XML object back into the webpage? Using a javascript library that is loaded into the browser? Something like Ajax? What if we want to reload the whole webpage? Do we use javascript to do that?

Edit:

What if the web server in this case is separate from the back-end application server? Should the client-side code call the web server to rout to back-end or call the back-end server directly when it wants to call a RESTful service?

Answer 1

There is nothing in REST or HTTP that dictates what should be returned to the client (html, json, etc). That is up to the application you are building.

The web as it has been for the last 25 years is "RESTful". You are following good REST design if you are following HTTP design, since HTTP is a protocol that implements REST constraints. So you are being RESTful if you are thinking about resources and using the HTTP verbs (GET, POST, PUT etc) to change the state of a resource on the server, rather than thinking about resources as verbs to do something on the server.

What has happened recently is people have build web application APIs that return JSON rather than HTML and have called this "RESTful" (even if they aren't) so the idea that you have to return JSON to be RESTful has entered the general consciousness. But you can return HTML and still be RESTful, since REST doesn't care what the server returns. The content type is simply a representation of a resource. What format that is in up to you and the client based on the Content-Types you are supporting. REST is agnostic when it comes to content type. You can return a HTML version of a resource and a JSON version of a resource depending on what the client says it can accept (in the Accept header of the request).

If you just need HTML then just return HTML. Only build a "single page app" if you have an actual reason for doing that. Twitter does that because they don't want the user to have to refresh the page to see new tweets and they also want to have a JSON API independently to the website and the website just acts as a client to the API. So the twitter.com page just pulls data from the twitter API and uses that to redraw a small bit of the page using Javascript. This only works (and some argue it doesn't work) because 99% of your time you just have the single page open. You are not moving through the site exploring different links.

Anything more than this, if you have a site that has links to follow and explore, then doing it using JSON and JavaScript redrawing is re-inventing the wheel. Some companies forget this and take the redrawing with JavaScript to a silly extreme. They have really complicated "single page sites" that are really multiple page sites but they completely redraw the page using data from AJAX when you click a link.

It would be far easier to simply use the web browser to go to another link. Your browser is already a REST/HTTP client. Make sure you have a valid reason to implement another REST client in JavaScript inside your REST client.

The tl;dr version - REST doesn't care about the Content-Type you use and there is no requirement in REST to use JSON or to have a single page app. If you have a multipage site and all you are doing is pulling down data in JSON and using that data to redraw the HTML of the web page it is far better to just use use HTML and the capabilities of your browser. If you need to support clients other than web browsers you can produce a JSON version of your resource along side the HTML version of resource and leave it up to the client to decide which version it wants.

Answer 2

As said by Robert, Yes! you technically correct. Generally at RESTFul level we have various Providers for JSON parsing which flows from server to client with help of RESTFul annotations. And reloading the there are various JS libraries which as JSON as model.

Popular combination which I've been using is Backbone and RESTFul. Its quite simple and ready to go combination.

Please refer backbone+rest for basic understanding

Answer 3

Yes, you are correct. There are all kinds of variations on the theme but this is the general concept of "single page web apps". The webserver delivers a "plain" html page and a bunch of javascript. The javascript calls restful services to get JSON (far easier to work with than XML in JS), parses that JSON, and then updates the HTML DOM accordingly. If the javascript wants to reload the entire page for some reason (like in a window.onerror handler or when the user clicks a 'logout' button), it can do window.location.reload() or window.location=urlOfSomeOtherPage.

There are all sorts of open source JS libraries that streamline building such applications. See Angular, Knockout, and Backbone (usually with Backbone.Marionette) as popular examples.