4 ms·
What makes REST impractical? And if REST isn't practical, we should use a different term to describe what we implement instead. The meanings of words should b
by mwcampbell 11y ago
What makes REST impractical?
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.
- dvanduzer 11y agoWhy 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.
- antod 11y ago> It's spelled ReST. Really? It's been capitalized REST everywhere I've seen it. Including here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch... You weren't thinking of 'reST' (reStructuredText) were you?
- dvanduzer 11y agoNo, 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.
- twistedpair 11y ago> "The meanings of words should be immutable" 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?
- stanleydrew 11y agoAt 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.