[coding123]

My main gripe with REST is that it's totally not future proof. The notion of RPC has been around forever. REST has basically completely replaced that. Http status codes and REST URLs are not future proof. We have already seen superior connection types (web sockets) come (and then basically go) that don't support the notion of URLs and (well they do for a second, but after that the original connection the URL is meaningless for the traffic flow). With Http2 we're seeing the return of lightweight connections (basically similar to websockets but have more graceful re-connection options). But http2 feels like a patch to me. I don't really want to bind the future of Apps to a bunch of URLs. I'd rather tie my app to a client that has a rich semantic set of objects and methods that pull down data, can update data, etc...

When we use REST as our layer to convey the API itself, we really lock ourselves down to a very specific set of URLs and HTTP Status codes. I'd rather have a rich error object thrown, not an HTTP status code that I have to examine.

I've had a pretty strong disdain for REST for the last few years and have been actively finding replacements. The closest I can come up with is Grpc. I'm dying waiting for Google to finish up Grpc-web however. If we continue to tie ourselves to a bunch of server resources by URL we're going to take forever to get off this archaic system that has no long term future.

[ako]

Do you think the web could have been built with RPC instead, and be just as successful?