In our work, we find it’s much easier to get ideas across if they can be referred to by name (compared to other approaches) and thus be made tangible. ROCA is an attempt to provide a reference for exactly this purpose.
It was the most reasonable and easy-to-remember name we could come up with that also resolved to a meaningful acronym.
Not at all. ROCA builds upon well-established concepts like REST and progressive enhancement, reinforcing their importance. (Some have called ROCA “a distillation of a decade of web development experience”.)
As with every architectural choice, there are trade-offs to be made. Sometimes strict adherence to ROCA principles is not practical or sensible, so it might be judicious to consciously depart from this path for selected parts of an otherwise ROCA compliant application. Of course one should be conscious of the costs associated with such a decision - however, that’s no different from other optimizations, e.g. database normalization.
You don’t – that’s the point. ROCA is intended to be framework-agnostic. You can pick any programming language, library, or framework, as long as you adhere to the aspects described above.
Frameworks are sometimes driven more by their authors’ personal taste, the intent to create something new, a desire to hide the Web and turn it into something different, or any combination of these factors. But even if they are totally in line with the ROCA guidelines, they can often be used in many different ways. That’s why we want to tie the whole thing more to how a Web application engineer approaches design than to any particular framework.
We plan to include a section on this, but would like to test the community’s reaction first. Frankly, we don’t want to risk ROCA being associated with any particular framework or even community.
We don’t think so; in our view, single page apps repeat the mistakes of unnecessarily fat server-side Web frameworks on the client side. The fact that the Web relies on a series of resource representations that are linked to each other is not a bug, it’s a feature.
Yes, everything is a resource, at least if we’re talking about the Web. Because that’s the whole point of it. If it’s a dashboard we’re talking about, then the resource is the dashboard; if it’s a portal you’re looking for, you might consider that your browser already does many things one usually expects a portal to do.
For example, instead of something like this:
… we prefer this:
<a href="<? $root_url ?>" id="root-url">Home</a> var uri = document.getElementById("root-url").getAttribute("href");
Of course not. The whole point of this site, though, is to give a reference that one can compare design decisions to.
The ROCA style itself is nothing new and can be seen in the wild in any number of Web applications. The name and this document have been created by Till Schulte-Coerne, Stefan Tilkov, Robert Glaser, Phillip Ghadir and Josh Graham, with lots of valuable input from a number of other folks, most notably from internal discussions at innoQ as well as a presentation on ROCA at SpeakerConf 2012.
This document is licensed under a Creative Commons license, i.e. you can essentially use it as you see fit, as long as you include proper attribution and share your modifications under the same license. We explicitly encourage you to recommend, compare or develop frameworks according to this style, and intend to be as open as reasonably possible while maintaining conceptual integrity.
Of course, please use the comments to share your thoughts. We welcome criticism as well as suggestions for improvement.