I'm saying if I wrote a "REST API" and everyone understood what that means, what would it matter whether or not it checks every box laid out by the originator of the term.
That makes it an effective form of communication, but not correct.
If I talk to someone who's not computer-savvy and they describe a workflow as "I put the USB in the CPU and then drag all my files onto my screen" (verbatim quote) I can figure out what they mean and work with them, but they clearly don't understand the concepts.
"There is no "correct" separate from usefulness in communication."
I think you may have misunderstood your source. Subjective truth is only half of the equation. The other half is testing rational models against experience. If you understand the constraints of REST, you understand that it has implications not met by the API in question and thus claims to be something which it clearly is not.
Just because I tell you I'm a duck doesn't mean I'm a duck.
I think Roy Fielding and the other strict REST proponents need to do a better job of explaining why we laymen should follow the rules so closely. I have read a lot of Roy's work, and those of other proponents', and I still don't see a lot of value in staying so strictly to the 'word' of REST.
Much could be helped by 'the experts' just showing us rational laymen the cost-benefit analysis. Show me how things will fall apart over time, some data would be helpful. And let me see some case studies.
Currently, my non-REST "REST" interfaces seem to be working pretty well. And, when they don't work, I go and fix them. Seems easy enough, but obviously I'm naive.
The reference is to Alice Through the Looking Glass by Lewis Carrol. It is a sad day when you can no longer expect an educated english speaker to have read the good Reverend's inspired nonsense.
