I've basically stared to do the following when creating a REST service:

  1. HTML is requested
  2. service returns the desired web page but without the requested "resource", eg. data
  3. web page contains JavaScript that issues AJAX request to the same service (different content-type)
  4. service then returns the actual data (JSON) and the page displays it

On one side it seems inefficient (2 requests) but then were I used this, "performance is of no concern", meaning low traffic internal app and the web sites are simple and load fast.

The reason I ended up with this is that the web page can then be almost pure Html + JavaScript and almost no server-side stuff is required, especially no loops, to create tables and stuff like that (which I think is very ugly compared to things like slickgrid), e.g. separation of data and view.

Now before I get to using this, is this a good idea or should I just stop doing it?

  • 2
    If you want to spend more time with your loved ones, and you desire to have free time to enjoy hobbies, or pursue personal goals, then for God's sake: Don't program applications like that! But if you like staying late at night and weekends in the office maintaining tons of "clever" code then suit yourself. Jan 4, 2013 at 23:06
  • 3
    Can you specifically elaborate whats you think is bad? Context: This isn't a 10 Mio LOC beast which is business critical. It's more like < 5000 LOC and doesn't matter if it doesn't work for a couple of days. Yes, that doesn't been i should do crappy stuff, hence elaborte what you think is so bad.
    – beginner_
    Jan 6, 2013 at 8:39
  • @begginer_ Every software begin small. What you describe rseembles a Rube Goldberg Machine: hammer hits man, man drops biscuit, parrot grab biscuits and tilts vase, etc. Jan 6, 2013 at 20:16
  • The reason this is done is often to improve performance, where fetching data can be done with multiple simultaneous requests to what may well be different servers. It doesn't seem like this applies in your case.
    – user16764
    Jan 10, 2013 at 15:49
  • How do you use this service from clients such as scripts, or from curl? Those things don't have javascript interpreters. Is this for a browser-only service? Jan 10, 2013 at 23:22

7 Answers 7


If you request a resource and it does not contain the data, than it's not REST service. The service providing the actual data in json might be, but the HTML part is not. For a web application it does not matter.

The technique works, but you need to be aware of it's limitations:

  1. Search engines don't interpret JavaScript, so site implemented like that won't be indexable by Google and the likes. For internal application it does not matter, for public facing one it would matter much.
  2. Users with special needs (like those using Braille terminals) use special browsers that are rather limited and may not interpret the JavaScript properly.

I would also note that the code generating the HTML is basically the same whether it runs server-side or client-side. You have much bigger choice of both languages and frameworks on server-side and I am sure there are several equivalents of slickgrid too.

You can, and should, still maintain separation of data and display on the server side. The template system can, and should, simply take the data as data structure or even json (especially if the actual service is in different language than the template system) and just expand a template with that data.

And no, I am not thinking about PHP; it's the least capable template system out there (though there are some better ones built on top of it). I am thinking Genshi or XSLT or something even more advanced that provides web widgets.

  • I write fat-clients in JavaScript, which do exactly this. But it's probably a bad idea for normal websites.
    – K..
    Jan 10, 2013 at 15:48
  • Why isn't it REST?
    – dagnelies
    Jan 10, 2013 at 16:55
  • 1
    If you distinguish between the "data" which forms the application (HTML, JS, CSS, etc.) and the "data" which the application displays (JSON) the JSON part is REST, but the part which loads "code" isn't. If you see the whole thing more abstract, both are.
    – K..
    Jan 11, 2013 at 10:30
  • "Search engines don't interpret JavaScript" - this hasn't been true for decades.
    – Dai
    Nov 21, 2022 at 12:47

There's nothing wrong with doing this, as long as you make sure to structure your code cleanly. You can even serve the static content from e.g. an Apache rather than your web service.

  • 2
    Apache is an overkill for static content. There are much faster servers. Most popular seems to be Nginx.
    – Jan Hudec
    Jan 4, 2013 at 8:04
  • 5
    That was an example, nothing more. Jan 4, 2013 at 18:21

This is a good practice. And it's done all the time, althogugh as @JanHudec points out, calling it a REST service is wrong. But many websites do exactly this for exactly the reasons you point out.

  • 1
    ... and the big reason that many do it is because data interaction is through services / JSON anyway, so it's likely better to handle all of your data interaction in the same way. (i.e. if you're using AJAX to refresh a table... you should also use it to build the table in the first place.) Jan 10, 2013 at 18:06
  • @ChadThompson Yeah, I find that a lot of the time if I don't build things like this in the first place, somewhere down the line I'll get a feature request to dynamically update the page based on the client doing something - which means that a simple implementation now leads to both the client and the server knowing how to build the page. It's easier to just build it on the client in the first place.
    – Tacroy
    Jan 10, 2013 at 23:43

I wouldn't call it an anti-pattern, what you're describing is more or less a fat client, not totally unlike services such as Trello. The server's initial responsibility is to send the DOM and whatever resources are needed to make the client work. I've worked on similar projects in data center automation and network monitoring.

The client starts off as a sparse DOM, pulls in some data via XHR (sometimes via JSONP) and finally attaches itself to a socket server. An even more basic example would be a chat application.

The only reason not to do it is that it can be extremely hard to get right. If you're comfortable with asynchronous functional programming and all of the races and other challenges it can present, then you'll have no problem maintaining it. More importantly, you'll have no problem writing it so that other people can eventually maintain it.

If the thought of adding more features begins to frighten you, or you begin to find that debugging is a nightmare, then you might want to consider other methods in production while you continue to experiment and learn.

It is a valid design as long as you're not digging a hole for yourself. If you have gobs and gobs of random JS everywhere instead of a clean interface then you probably want to re-factor or go about the project differently. Most of your functions that are defined to execute once all resources load should be anonymous and entered from a clean interface. If they aren't, you might be headed for trouble.

  • What do you mean by "random JS"? In my case what you are describing above is a lot more complex what I have (a few input fields and a table (slickgrid) or jquery ui tabs). That is it. About 200 LOC per page.
    – beginner_
    Jan 15, 2013 at 7:41

as @Jan Hudec said, your approach can definitely not be called REST. Though the part where the client requests for a resource could be. It is better if the client handles the presentation part, like backbone does. It communicates with the REST server for the resources and displays them using views.


It may be an anti-pattern, but I think it's also the future of web applications. Rather than mucking about with JavaScript, however, you should be using a templating library at the least. A better solution is a client-side MVC framework like AngularJS (which I happen to be using now).

For some more references, here's a popular blog post comparing several frameworks, and here's a site that implements the same program using multiple frameworks.

Also: Jan Hudec's comments about search-engine interaction and screen readers are valid. If you're working on an eCommerce site (where pagerank matters), then you probably don't want to use client-side frameworks. But for internal apps, these aren't usually concerns.

  • thx never heard of AngularJS. But I think for my current needs it is too much.
    – beginner_
    Jan 15, 2013 at 7:44

What your doing sounds good! However if your json responses contain any HTML then your wasting your time.

Another point though is your dumb client should probably getting its json data from a different project. You should aim for proper separation between client and service then you will have a proper RESTful service

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.