[sneak]

I've done JSON-RPC at scale before and the one downside to it is that you have to write a custom caching proxy for readonly calls that understands your API.

With REST you can just use a normal HTTP caching proxy for all the GETs under certain paths, off the shelf.

Using a hybrid (JSON-RPC for writes and authenticated reads, REST for global reads) would have saved me a lot of time spent building and maintaining a JSON-RPC caching layer.

There is benefit to a GET/POST split, and JSON-RPC forces even simple unauthenticated reads into a POST.

The other issue with JSON-RPC is, well, json. It's not the worst, but it's also not the best. json has no great canonicalization so if you want to do signed requests or responses you're going to end up putting a string of json (inner) into an key's value at some point. Doing that in protobuf seems less gross to me.

[throwaway4good]

Personally I prefer to have explicit control over the caching mechanism rather than leaving it to network elements or browser caching.

That is explicity cache the information in your JavaScript frontend or have your backend explicitly cache. In that way it is easy to understand and your can also control what circumstances a cache is invalidated.

[sneak]

> Personally I prefer to have explicit control over the caching mechanism rather than leaving it to network elements or browser caching.

I'm not talking about browser caching, I'm talking about the reverse proxy that fronts your ("backend") service to the internet. High traffic global/unauthenticated reads, especially those that never change, should get cached by the frontend (of the "backend", not the SPA) reverse proxy and not tie up appservers. (In our case, app servers were extremely fat, slow, and ridiculously slow to scale up.)

[throwaway4good]

I am sure you have good reasons for your concrete design but in the general case: Why not simply build the caching into your backend services rather than having a proxy do it based on the specifics of http protocol? It would be simpler and far more powerful.

[sneak]

Because the backend app servers were extremely fat (memory and disk intensive) and every request they served that could have been served from an upstream cache was a request that they weren't serving that actually required all of their resources to serve.

Caching upstream on (vastly cheaper) instances permitted a huge cost savings for the same requests/sec.

[mkranjec]

Proxy caching / leveraging caching to external service makes sense when you have a LOT of users scattered around the globe - let Akamai/Cloudflare take care of edge node caching and maintenance. In the end it saves you a lot of engineering time and infrastructure costs not mentioning user experience. YMMV but it pays off in our current setup.

[tatersolid]

Because if you use HTTP caching, you can use a CDN with 100s of global locations. Which is quite a bit more powerful than any custom solution.

[hashkb]

If I'm going to neuter HTTP like that, I at least do RPC over websockets for realtime feel. And I still usually run it through the whole Rails controller stack so I don't drive myself insane.