[BringTheTanks]

My premise is that HTTPs-only and REST have opposing constraints.

You have not demonstrated any flaws in it, REST says communication is stateless and cacheable except for acknowledging some select minority cases when it's not the case.

Turning the minority cases into the only way of communication nullifies most of the benefits of REST, because the whole rationale of the paper is lost. I.e. intelligent shared processing and caching by intermediaries.

I'm taking no stance on what "the reality is". I'm taking no side about which side is more correct. I'm stating what both sides want, and finding it curious they don't see the contradiction.

[smsm42]

I think the description of REST you've outlined is not entirely right. The statelessness relates to client state, not the system state - i.e., POST/PUT/DELETE etc. can very well change the system state and that's the whole point of them - and also session state is allowed too, it's just not the part of REST architecture but is assumed to be implemented externally.

It is true that HTTPS may impede some cacheable resources. Maybe HTTPS may be improved to allow transparent caching of _some_ content, but the security implications may be hard to predict and will require very careful implementation to not introduce new security issues with attacks on caches themselves (DNS system still has this problem AFAIK).

[BringTheTanks]

The statelessness relates to communication state. A client can hold state and it most certainly will hold state (consider your browser: open tabs with URLs, bookmarks, local browser cache; form autocompletion; settings; all of this is "state").

Instead, REST talks about a request being stateless and a response being stateless (i.e. sufficient on its own and not dependent on preceding or future communication between that client and server).

This is, again, done for the benefit of intermediaries, because intermediaries should not be forced to hold state in order to interpret REST communication. Every request, response should be sufficient on its own to be understood.

[smsm42]

Sorry, I was not clear - by "client state" I meant not "state kept on the client" but "state on the server that is kept different for every client".