And REST as Dr. Fielding says it is is not as practical to implement as it should be. Hence the need for RESTful which just draws influence from his work.
You are downvoted, but also accurate. HTTP 1.0 happened, then Fielding did his work, informing HTTP 1.1. Chronologically speaking, REST is something that describes the web and how it succeeds.
> Chronologically speaking, REST is something that describes the web and how it succeeds.
Chronologically speaking, REST is an attempt to fit the relatively-organic growth of the web into a systematized conceptual framework, and a totally untested theory about how it succeeds.
On the first count, it obviously is incorrect. You even pointed out that Fielding points this out! Any part of the web that uses cookies is not RESTful! So REST is not something that "describes the web", it describes an idealized version of the web that in fact has only a tiny fraction of the functionality that the actual web has.
On the second, as far as I'm aware, there is absolutely no evidence supporting Fielding's claims about the relationship between the properties of REST and the success of the web. We may or may not find his points persuasive (I do find his points somewhat persuasive), but please remember that this is someone's thesis, in every sense of that word.
And if REST isn't practical, we should use a different term to describe what we implement instead.
The meanings of words should be immutable, to avoid confusion. No, that's not how language has historically worked, but we can do better. After all, there are a lot of things we have historically done that we don't want to keep doing.
At a high level, REST is impractical for machine-to-machine interactions where there is no immediate user and hence no need for a user-agent. REST is amazingly practical for things like the human-readable web that we know and love.
If Stripe, e.g., were to build a truly REST machine-to-machine API then they wouldn't need to create any documentation of "endpoints". Developers would only need to point a generic REST client at the API's root URL and all the other endpoints would be discoverable from there.
This is impractical, because a machine-to-machine API will generally know that it wants to charge a credit card or update a billing address and will reap benefits of knowing exactly how to do that without the overhead of going to the root of the API and navigating the resource tree every time.
It can be summed up like this: pure REST is practical in situations where tight-coupling of a client and server's interactions is undesireable. In machine-to-machine interactions, there is almost always some value in tight coupling, or at least a level of coupling that pulls the system away from being "pure" REST. Hence it's rather impractical.
Since when has language historically worked that way? Ever wonder why we have words with 7 officially accepted definitions? Because usage and interpretation changes with time. Perhaps you're confusing language and mathematics?
Why would speaking a human language without nuance, without any possibility of misinterpretation, be a step forward?
It's spelled ReST.
Does that better convey what it means in that string of characters? Maybe for some values of human. But words are for humans, and humans are not immutable, so our words shouldn't be.
No, I was thinking of Representational State Transfer, which is what Fielding's paper talks about. And I was also thinking about how people say RESTful, and how that's a confusing way to say "conforms to how Roy Fielding thinks an API should behave."
What I was responding to was advocacy that human language should behave the way we expect RFCs to work.
Nonsense. REST is what Dr. Fielding says it is, because he coined the term.