“In my protocol all client state transitions are valid and the client does not need to discover URIs because it controls the URI space. Hence there is no hypermedia.”

In your presented scenario, your server provides no transitions, so I think the above statement should read, “the client has no state transitions; once it makes a request it’s done.” That would certainly satisfy the hypermedia constraint. I don’t mean to say that other approaches aren’t possible, only that you are correct in saying that this isn’t REST.

Second, I completely disagree about your comment about adding -er or -or to the end of words. Such words are called agent nouns, and a quick Google search will reveal that these are considered grammatically correct, even if the word isn’t in the dictionary per se. In computing, we often use words that aren’t in the common English dictionary, as they are highly technical terms. Adding -er (or -or if it fits better) to the end of a verb is a good way create a noun describing something that performs the action of that verb. Without this, we’d have to use awkward constructs like DeletingObject (or replace “Object” with any one of your so-called generic words).

I also disagree with your argument that this should be avoided because non-English speakers won’t understand them. If we take this argument further, we should use as simple of English as possible, sacrificing any complex words, even if they are much better descriptors of what we want. This is a grammatical part of the English language, and if we really want to avoid poor names, we should take advantage of all that the language has to offer us.

That REST is now a somewhat vague concept Is not entirely a bad thing. Most of our natural language is ambiguous and poorly defined. You can see this in legal documents and technical specifications which sometimes struggle to define the precise meaning of such common words as “must”. We can still have reasonable conversations as long as we don’t insists that our words have precise meanings that they don’t actually have.

I’ll continue using REST as a generic umbrella term in casual conversations, mostly because I cannot not think of any other alternatives that serve this role better. After all, the phrase “HTTP-based protocols that are not SOAP and show at least certain aspects of what used to be known as REST” doesn’t seem to be catching on.