undefined | Better HN

0 pointsseemslegit6y ago0 comments

Contrasting REST with RPC makes more sense, while REST apis map quite naturally to RPC as the other way around is more convoluted.

But a dedicatd RPC stack such as grpc or thrift constraints my architecture in other ways, that json-over-http doesn't.

And what are those unavoidable costs of REST that are not just the wire overhead of HTTP ?

0 comments

kragen6y ago

Proxies, built-in retry semantics in many clients, code complexity for dealing with the mandatory flexibility in HTTP, the presumption that GET is safe for, say, prefetching or spidering, etc. I think REST is often worth the cost (I might be the only person on this thread who has written an HTTP server in assembly), but if you're not using REST, using HTTP will tend to cause you a lot of headaches you could have avoided, for little or no benefit.

“But firewalls!”

bostik6y ago

I would think this is orthogonal to REST-vs-RPC:

> the presumption that GET is safe for [reads]

GET requests are supposed to be idempotent and side-effect free. Sadly, too often, they are not. Internal state gets mutated, a query parameter gets stored and/or processed in a way that affects future reads, and so on.

But then again, nothing prevents you from writing RPC based service with those semantics either. It just might be that people who develop and maintain RPC services are better aware of the consequences of their actions.

REST is conceptually easy, has human-readable on-the-wire payloads and operates on synchronous semantics.[×] The bar for entry is simply lower, allowing even an inexperienced developer to get going with very little friction.

The very fact that I can do this:

    import json, requests
    dada = json.loads(whatever)    
    res = requests.post(URL, data=dada)

... means it's incredibly easy to get off the ground and shuffle data between services. Conversely, it's also easy to send the wrong data, in a wrong way.

×: webhooks are effectively callbacks, but instead of setting the code entry point for async return in your call, you expose a webhook route and treat it as any other request.

kragen6y ago

Your example code uses HTTP but not REST. This explains most of our apparent disagreement; what you are talking about when you say “REST” has very little to do with REST itself. REST is not conceptually easy; it's just that people frequently confuse it with HTTP.

j / k navigate · click thread line to collapse

0 comments

kragen6y ago

“But firewalls!”

bostik6y ago

I would think this is orthogonal to REST-vs-RPC:

> the presumption that GET is safe for [reads]

The very fact that I can do this:

    import json, requests
    dada = json.loads(whatever)    
    res = requests.post(URL, data=dada)

... means it's incredibly easy to get off the ground and shuffle data between services. Conversely, it's also easy to send the wrong data, in a wrong way.

×: webhooks are effectively callbacks, but instead of setting the code entry point for async return in your call, you expose a webhook route and treat it as any other request.

kragen6y ago

j / k navigate · click thread line to collapse