4 ms·
Lots of comments here arguing REST is popular because it's easy, but there's another higher level reason too: it forces you to think about the network. In far
by speedplane 9y ago
Lots of comments here arguing REST is popular because it's easy, but there's another higher level reason too: it forces you to think about the network.
In far too many RPC protocols, calling functions that operate over a network are treated like normal functions. A function call, almost by definition, fails to take into account network errors, and race conditions where multiple events overlap. Network calls are not function calls, and the fact that REST calls are relatively distinct from normal function calls is a good thing.
- qaq 9y agoAnd yet most popular "REST" APIs provide lang. specific clients that expose regular function calls to consume the API turning it into RPC.
- addicted 9y agoSure. Those are conveniences. However, most of the Getting Started articles that you find about any publicly published REST API usually starts you off with a bunch of curl commands. Even if the networking aspects are completely hidden from you in your application, your formative experiences with the REST API almost certainly was with the network requests.
- speedplane 9y agoGiven the dozens of languages and libraries that interact with APIs, I don't see the issue of starting with a curl command. It's a common denominator, programmers of almost all languages understand, like international sign language. No one would seriously use curl commands in production, but load up a command window, and it's an easy way to start messing around. Agree with your second point though... network requests are hard. They are not much different from real distributed programming. Making REST requests should be done with care.
- empath75 9y agoI do use curl commands in production for stuff like user data in an aws cloudformation template. Having an api I can hit with curl that returns json I can parse with jq is super convenient.
- matt_kantor 9y agoI don't think the parent commenter sees curl-centric getting started guides as an issue either. Actually from this thread's context I assumed they thought it was a good thing.
- Yokohiii 9y agoIf a network (or endpoint) fails you usually only few options during runtime, retry, skip, stop. That is pretty much all you want to know. Everything else is specific to the endpoint, which is more about contracts and constraints then about networking. You either use the endpoint correctly of not. I.e. using a database like MySQL has similar constraints. And decent engineers know how to work with it and where it is happening.
- jstimpfle 9y agoYep, and no amount of REST / other introspective boilerplate can help about the fundamental problem of not being synchronized. There is no solution to the "A knows X, but B does not know that A knows X, or A does not know that B knows that A knows X, or B does not know that A knows that B knows that A knows X..." problem. Other than that, I think at some level networking is nothing more than function calls that can take a long time and/or fail.
- borplk 9y agoThe "force to think" part gets real old real fast though. It's fine, people can understand "this function does network I/O so be careful".
- digi_owl 9y agoI worry that this is something that can be applied to programming in general these days. Back in the day of the C64 etc, programmers had to worry about the underlying hardware as they were for the most part working with assembly. But as increasingly abstract languages have come to be (most modern ones use virtual machines and garbage collectors), the programmer never have to consider the hardware their code has to interact with at some point. End result is all manner of bloat and memory leakage.
- jstimpfle 9y agoI don't think you closely read what parent wrote. Do you think a function call is "too abstract" because "nobody knows what it's doing under the hood"?