21 The REST versus SPA Dilemma
REST stands for REpresentative State Transfer, and SPA stands for Single Page Application. These terms both apply to web-borne applications.
In a REST application (or web-site), the URL (Uniform Resource Locator) carries the state information. For instance, we could go to an internal web-site named Example to log in, and then get directed to Example/MainPage for our main menu page. If I then select “Employees” to see a list of employees, I’d then be at the URL Example/Employees. If I then select employee #100, the URL might change to Example/Employee?id=100. Note the “?id=100” part of the URL. That is the “argument”, setting “id” to 100. If there are multiple arguments, they will be separated by “&”, for example, “?id=100&dept=10”. Pro: You can bookmark pages in a browser, and come back to that location in the browser, such as employee #100, without having to track through the menu system. Con: Each time the application goes to a new URL, the whole page needs to regenerate and reload.
In a Single Page Application (or web-site), portions of the page are loaded through AJAX (Asynchronous JavaScript And XML) calls, in which the web page makes a request to the server in a form of an AJAX packet, and receives a response from the server, which it then uses to modify itself. It doesn’t matter to us as requirements writers, but the request and response also typically moves via the HTTPS protocol, and any data is typically transmitted as arguments, with the response typically being in the form of JSON, HTML, or XML. The pros and cons are exactly the opposite of REST: Pro: Faster than REST, because only pieces of pages are being generated and transmitted. Con: There is no way to save or restore the state from the user’s end.
The reason this is being brought up here is because the difference between REST and SPA applications is visible to the user, and must be decided as a part of the requirements when the application is in the form of a web-site.
If you look at job listings, you’ll see ads for REST programmers, and other ads for people with significant SPA experience. That’s because there is one group who know that REST is the right way to do things, and that SPA is not. Of course, there’s that other group who know that SPA is the right way to do things, and that REST is not. Sheldon’s advice: Agree with the boss or customer. If they don’t have an opinion, and the site is customer-facing and single use, use SPA. If the site is internal-facing and continuous use, use REST. If it’s external and continuous, or internal and single, it’s a toss-up.
