Json Rpc Means
To understand what json rpc means, know it is a remote procedure call rule. It uses plain text JSON messages to run functions on a remote server. Teams set up this protocol by sharing an endpoint between a client app and a server. If teams grant overly broad role permissions on that endpoint, any client can run dangerous methods. A single exposed key can let an attacker read or change backend data. What json rpc means for your app setup In a standard setup, a client app sends a message to a s
JSON Web Tokens (JWT): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To understand what json rpc means, know it is a remote procedure call rule. It uses plain text JSON messages to run functions on a remote server. Teams set up this protocol by sharing an endpoint between a client app and a server. If teams grant overly broad role permissions on that endpoint, any client can run dangerous methods. A single exposed key can let an attacker read or change backend data.
What json rpc means for your app setup
In a standard setup, a client app sends a message to a server. This message contains the method name, the input values, and a unique request ID. The server reads the message, runs the named function, and sends back a reply. The reply holds either the result data or a structured error object. Both the request and the reply use the same ID to match calls.
Teams can send these messages over HTTP, WebSockets, or raw TCP sockets. Unlike REST, this protocol does not use many URL paths or HTTP verbs. Every call goes to a single endpoint, and the payload names the action. A client can also send a notification, which is a request without an ID. The server runs the notification method but does not send any reply back.
How teams set up roles and permissions
To lock down the endpoint, teams set up role checks on the server. The client app must log in with a token or key first. The server checks this key against an internal list of allowed roles. Many teams group methods into read roles and write roles for safety.
Developers also use batch requests to send many calls in one network trip. The client packs an array of request objects into one JSON payload. The server runs each method in the batch and returns an array of replies. Teams must check permissions for every single item inside that batch array. If one method fails a role check, the server rejects only that item.
JSON Web Tokens (JWT): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native setup solves and what it misses
Native role checks solve the basic problem of who can reach the server. They block unknown callers and stop basic apps from running admin methods. This setup works well when every method does only one safe task.
Still, endpoint login checks leave a large gap during daily operations. The setup decides who logs in, not what individual requests do in flight. Once a client passes the role check, the server trusts the input values. A valid user or AI agent can still send bad parameters or request huge data dumps. Standard HTTP logs only show that someone posted data to the main URL. They do not log which method ran or what sensitive data came back. If a reply contains emails, phone numbers, or card numbers, the client gets everything. Without payload checks and field masking, teams cannot control what happens inside a session.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does JSON-RPC differ from REST APIs?
REST maps actions to many URLs and HTTP verbs like GET or DELETE. JSON-RPC sends all requests to one URL and puts the action name inside the payload.
What is a notification in a JSON-RPC workflow?
A notification is a one-way message that leaves out the request ID field. The server runs the requested method right away but sends no response back.
Why are JSON-RPC calls hard to audit with standard web logs?
Standard web logs only record the single URL path and the HTTP status code. They do not capture the method name or arguments hidden inside the request body.