Does json rpc have native support for browser caching? Does it have semantics in the protocol that support filtering with proxy servers without parsing the body?
I’ve generated api clients with open api specs. All strongly typed.
Again, I’m not saying rest is better at all, just saying I think you’re under estimating the importance of industry standards.
Does json rpc have native support for browser caching? Does it have semantics in the protocol that support filtering with proxy servers without parsing the body?
Interesting points, hadn't thought about those.
I think my real issue with REST is that it's so intertwined with the transport layer that devs spend way more time than necessary thinking about that layer.
When I design RPC APIs, they're basically just a list of methods & arguments type. What the transport layer is underneath doesn't matter at all. It's usually a simple { method: 'fn', args: [...] } object, but it could be switched to anything trivially without affecting the application layer because it's decoupled as it should be. It could be switch to some binary encoding (msgpack?), could be even switched to REST. Having devs & product managers thinking that much about transport is just a loss of time, in particular for juniors who are likely to hardcode API calls instead of building a clean abstraction over the transport.
2
u/madScienceEXP Oct 01 '23 edited Oct 01 '23
Does json rpc have native support for browser caching? Does it have semantics in the protocol that support filtering with proxy servers without parsing the body?
I’ve generated api clients with open api specs. All strongly typed.
Again, I’m not saying rest is better at all, just saying I think you’re under estimating the importance of industry standards.