Resource-oriented client architecture (ROCA)

What is ROCA ?

Recently I've encountered ROCA - resource-oriented client architecture, which is a lightweight set of recommendations / guidelines for a good web application architecture. It's available here: http://roca-style.org.

Downsides

After reading thru I can say that authors tended to stay conservative in their approach, especially regarding front-end. It's usually a good thing, as typical development process usually relaxes the rules set at the beginning (due to lack of time, business pressure etc.) so being too constrained at the beginning usually means appropriate constraints at the end ;-)
In ROCA case however, I have following comments:

"JavaScript is used unobtrusively and the application remains usable (albeit with a decrease in usability and convenience) if JavaScript is disabled."

Well, this one is rarely possible nowadays. Most rich web applications use a lot of JavaScript not only to make UX better, but also for core processing (transformation of data from REST, validation etc.). For applications (SPAs) based on JS frameworks (Angular, vue, react, ...) it's totally impossible. It's also not practical to provide a separate, HTML-only version for clients without JavaScript, taking into account decent support of JS by all modern browsers and OSes.

"The same functionality must not be implemented redundantly on both the client (JavaScript) and the server. Thus, due to the application logic requirement, application logic must not reside on the client-side."

This one is also hard to apply in modern web apps. I believe that it's good to minimise redundancy, especially regarding "heavy" business logic. But parts like data validation are often implemented in both places. Backend needs to do it in order to maintain data consistency. Frontend needs to do it in order to provide better user experience (interactive feedback).

"All JavaScript code and CSS code must be static, and must not be dynamically generated by the server in a form specific to the resource requested"

Out of my personal experience, there are some solid cases when JavaScript has to be generated online. One example is a distributed system in which parts (let's call them "microservices" ;-) ) can be turned on/off, virtually enabling/disabling parts of the frontend. Then, such change has to be reflected in JavaScript returned. However these are very specific and therefore limited cases.

Upsides

Rest of the rules I'm OK with. Some sound very basic in modern world (like "server adheres to REST principles" or "client uses RESTful HTTP queries"). Others, however, are more tricky, easy to miss during web app develpoment and should be reminded, like:

"A user must be able to link to a specific piece of information, e.g. by copying the address from the browser's address bar and pasting it into an e-mail, creating a bookmark, or using any of the fancier ways to share URIs."

or

"The browser controls like the back, forward and refresh buttons must work as expected. I.e. the back button should take the users where they expect to be taken to (the last meaningful resource they worked with). A browser refresh should not cause a re-rendering of the login or home page instead of the page the user was looking at, or a (to the user) unexpected question about wanting to submit the same data again (when the user doesn't recall submitting any data, indicating a mis-use of the POST verb)."

Summary

To sum up, I think that ROCA is a good idea worth reading (especially during project's start). However as any given kind of recommendations, should be applied carefully, with respect to the domain and problem.