Hacker News Reader

Comment by francislavoie | Hacker News Reader

I use https://www.jsonrpc.org/specification. I hate REST. With JSON-RPC, I can have true 1:1 mapping on both ends to how I write code, and it's transport agnostic. Doesn't rely on any language. I use PHP in the backend, TS in the frontend.

There are ways to make it somewhat type safe with tools like https://open-rpc.org/ but I tend to just go vanilla with it and write TypeScript types in the frontend for the results on the frontend.

View on HN

In all honesty, we do this with REST now. Just define interface with OpenAPI - then create clients, servers in virtually any language you like.

The problem with REST for me is that it locks you to HTTP verbs and URIs. And it's not a great mapping for much more than CRUD. I find it really restrictive and annoying. It's specific to HTTP as the transport, so I can't use REST over websockets or some raw TCP server-to-server pipe, etc, without making a kludge of it.

This is actually really cool! Any chance you can point me to an implementation for JSON-RPC? I'm interested to see the benefits with JSON-RPC over a traditional REST API.

The spec explains pretty much everything you need to know. Look for a client and server implementation in your language of choice; essentially all it needs to do is decode the JSON message and validate that it uses the right structure, and handle message IDs for batching, then call your custom message handling logic.

Over HTTP, basically you just have a single endpoint which always takes POST requests, and always responds with 200 status, even on errors. If you're using this in a frontend JS application, you'd want a wrapper over fetch() which rejects the promise if the RPC response has an error in the message.

Reply on news.ycombinator.com