Is this "anti-pattern" and should I stop using it or is this clever design?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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