Comments by "Jeremy Chone" (@JeremyChone) on "What Is REST API? Examples And How To Use It: Crash Course System Design #3" video.

  1. We moved from REST to JSON-RPC for all our remote APIs. Much better representation for remote function calls. It made the whole http method to function call mapping gymnastic disappears. We wish we would have done so 10 years ago.
    5
  2.  @JustinShaedo What do you mean by better supported?
    1
  3.  @JustinShaedo  Hmm, I'm not sure what "natively supported by browsers" means. JSON-RPC is simply JSON over an HTTP POST. In fact, it's a subset of REST in terms of the protocol and HTTP method used. So, assuming we make our requests with the browser's XHR or the new Fetch API, there's nothing more the browser needs to provide to support JSON-RPC over REST, since JSON-RPC is a subset of REST.
    1
  4.  @JustinShaedo  Thank you. Yes, we have been building large applications using JSON-RPC for many years now, and it has worked extremely well. We even provided an API to our clients' developer users, and they loved it. It's very simple: just an HTTP POST with JSON in and out, featuring a minimal top-level structure. It works in any browser, any client, with no stubs or SDK needed. Developers can find more information by searching for jsonrpc online; the specification is incredibly straightforward. In fact, we use it in our rust10x blueprint (a Web App production blueprint), and it works like a charm. I've made an extensive video about it, with more to come. There are many myths about json-rpc, but once its simplicity and versatility are understood, it resolves many issues. No more REST gymnastics for function calling, and best of all, it's protocol-independent. We can use it for network calls, WebView to Backend calls, like Tauri commands, or even in message passing in an actor model. However, there's no absolute best way to code large production applications. If developers are more comfortable with REST or gRPC, that's completely respectable too. Happy coding!
    1