Hacker News Reader

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

View on HN

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