Is REST a good choice for GUI web applications?

Question

GUI based web applications could be build upon a GUI component, stateful framework like Wicket or they could build in a RESTful, stateless way with GUI status only on the client.

From a technical point of view REST looks like the right way since it leverages the full power of http and leads to highly scalable applications. But that comes at a price. Complex GUIs will require a JavaScript application on the client in many cases. You have to stay on the same page and reload only parts, if state should be maintained on the client. Or you have to use tricks with hidden iframes. Sometimes there are pseudo resource like shopping carts on the server, to enable a RESTful design. You have to maintain intermediate state of multi step dialogues and so on ...

If I look around there are very few RESTful GUI webapplications. Is this because of historical reasons or is a RESTful design unproductive in common scenarios?

Answer 1

If I look around there are very few RESTful GUI webapplications. Is this because of historical reasons or is a RESTful design unproductive in common scenarios?

My answer is subjective, but in my opinion, two major hurdles hinder RESTful development:

1. Change - it very different from the way sites are traditionally designed
2. Challenge - designing a pure RESTful server API and a corresponding rich, robust client UI isn't easy

Complex GUIs will require a JavaScript application on the client in many cases.

In my opinion, a complex, a rich client-side experience is going to require some in-depth JavaScript, regardless of the server-side implementation.

You have to stay on the same page and reload only parts,

This is a very different design from the traditional request/response full-page-to-full-page design. Each design has its own trade offs. REST designs work particularly well with AJAX calls, but the client-side code requires careful design to be maintainable and robust.

A RESTful server with a thick-client:

• scales well: session information for every user isn't stored in scarce server memory
• less request/response data over the wire: not sending every page in full, not sending session IDs or ViewStates
• clean reusable URLs: provide a clean, decoupled server API that can support multiple UIs
• pure: strict adherence to the HTTP specification (GETs cause no side effects, etc.)
• client experience: richer, more responsive with asynchronous transactions

However, as you mentioned thick-clients have drawbacks:

• more vulnerable to XSS attacks, RESTful URLs really need careful security
• complex JavaScript can be challenging to develop, maintain, and debug (using OO JavaScript can help mediate this)
• there is a need to indicate to the user that asynchronous requests are processing in the background
• more client-side failure-handling logic is required
• frameworks and IDE tools have been traditionally weaker for client-side development, compared to server-side (this is slowly getting better)