Is REST a good choice for GUI web applications?

Question

GUI-based web applications can be built on a GUI component in a stateful environment, for example, in Wicket, or they can create RESTful, regardless of the state of the GUI, only on the client.

From a technical point of view, REST looks right, because it uses all the power of http and leads to scalable applications. But it comes at a price. In complex GUIs, in many cases the client requires a JavaScript application. You should stay on one page and reload only parts if the state should be supported on the client. Or you need to use tricks with hidden frames. Sometimes there are pseudo resources on the server, such as shopping carts, to enable RESTful design. You must maintain an intermediate state of multi-stage dialogs, etc ...

If I look around, there are very few RESTful GUI web applications. Is this due to historical reasons or is it a RESTful project, unproductive in common scenarios?

Answer 1

If I look around, there are very few RESTful GUI Web applications. Is it due to historical reasons or is the RESTful project unproductive scripts?

My answer is subjective, but, in my opinion, two main obstacles hinder the development of RESTful:

• Change - this is very different from the way sites are traditionally designed.
• The challenge is to design a clean RESTful server API and a corresponding rich, reliable client interface is not easy.

Complex GUIs require a JavaScript client application in many cases.

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

You should stay on one page and reload only parts,

This is a completely different design from the traditional full-page request / response design. Each design has its own trade-offs. REST constructs work especially well with AJAX calls, but client code requires careful development to be convenient and reliable.

RESTful server with a thick client:

• scales well: session information for each user is not stored in the server’s limited memory.
• less cable request / response data: do not send every page completely, do not send session identifiers or ViewState s
• pure multiple URLs: provide a clean, decoupled server API that can support multiple user interfaces.
• pure: strict adherence to the HTTP specification (GET does not cause side effects, etc.).
• customer experience: richer, more responsive with asynchronous transactions

However, as you said, fat clients have disadvantages:

• more vulnerable to XSS attacks, a RESTful URL really needs careful security.
• complex JavaScript can be difficult to develop, maintain, and debug (using OO JavaScript can help notify you about this)
• you must tell the user that asynchronous requests are processed in the background
• additional client-side error handling logic required
• IDE frameworks and tools are traditionally weaker for client-side development compared to server-side ones (this is slowly improving).

Answer 2

RESTful GUI projects are very productive, IMHO. You can use many functions without additional work to support corner cases, such as re-sending user information, browser history (back and forth) with several tabs and windows. If I am not mistaken, this site uses the RESTful user interface.

Answer 3

REST was determined by the observed characteristic of successful web applications, both GUI and M2M. Therefore, by definition, this should be appropriate for these cases.

I also noticed that you asked a question about desktop and web applications . You might be interested to know that REST is a great architecture for building client desktop applications. I have written several desktop clients that receive all their data from a REST server.