The very link you provided says that client-side execution of server code is an optional constraint: >The notion of an optional constraint may seem like an oxy

The very link you provided says that client-side execution of server code is an optional constraint: >The notion of an optional constraint may seem like an oxymoron. However, it does have a purpose in the architectural design of a system that encompasses multiple organizational boundaries. It means that the architecture only gains the benefit (and suffers the disadvantages) of the optional constraints when they are known to be in effect for some realm of the overall system. For example, if all of the client software within an organization is known to support Java applets [45], then services within that organization can be constructed such that they gain the benefit of enhanced functionality via downloadable Java classes. At the same time, however, the organization's firewall may prevent the transfer of Java applets from external sources, and thus to the rest of the Web it will appear as if those clients do not support code-on-demand. An optional constraint allows us to design an architecture that supports the desired behavior in the general case, but with the understanding that it may be disabled within some contexts. I think this means you only do it when it makes sense. Perhaps this is too open-ended as you can run basically anything on the client, including a full application. But I think the stateless requirement means you should not require that the server be bothered with the client state, and that the client state should be easily recoverable from the resource URI. But I don't actually know. You don't have to commit to using REST principles if you don't want to. I think it was proposed as a way to reduce server load and bugs, not as a way of life.