JSON-RPC

JSON-RPC funciona enviando una solicitud a un servidor que implementa este protocolo. En ese caso, el cliente suele ser un programa que pretende llamar a un único método de un sistema remoto. Se pueden pasar varios parámetros de entrada al método remoto como una matriz o un objeto, y el propio método también puede devolver varios datos de salida (esto depende de la versión implementada).

Todos los tipos de transferencia son objetos únicos, serializados mediante JSON.^[1]​

Solicitud#edit

Una solicitud es una llamada a un método concreto proporcionado por un sistema remoto. Puede contener tres miembros:

• method: una cadena con el nombre del método que se va a invocar. Los nombres de método que comienzan por «rpc.» están reservados para métodos internos de RPC.
• params: un objeto o una matriz de valores que se pasarán como parámetros al método indicado. Este miembro puede omitirse.
• id: una cadena o un número no fraccionario que sirve para relacionar la respuesta con la solicitud a la que responde.^[2]​ Este miembro puede omitirse si no debe devolverse ninguna respuesta.^[3]​

Respuesta#edit

El receptor de la solicitud debe responder con una respuesta válida a todas las solicitudes recibidas. Una respuesta puede contener los miembros que se indican a continuación:

• result: los datos devueltos por el método invocado. Si se produjo un error al invocar el método, este miembro no debe existir.^[4]​
• error: un objeto de error si se produjo un error al invocar el método; en caso contrario, este miembro no debe existir.^[5]​ El objeto debe contener los miembros code (entero) y message (cadena).^[6]​ Un miembro opcional data puede contener datos adicionales específicos del servidor. Existen códigos de error predefinidos que siguen los definidos para XML-RPC.
• id: el identificador de la solicitud a la que se responde.

Como hay situaciones en las que no se necesita ni se desea una respuesta, se introdujeron las notificaciones. Una notificación es similar a una solicitud, salvo por el id, que no es necesario porque no se devolverá ninguna respuesta. En ese caso, la propiedad id debe omitirse (versión 2.0) o ser null (versión 1.0).

En estos ejemplos, --> indica los datos enviados a un servicio (solicitud), mientras que <-- indica los datos que llegan desde un servicio. Aunque <-- suele llamarse respuesta en la computación cliente-servidor, según la versión de JSON-RPC no implica necesariamente una contestación a una solicitud.

Versión 2.0#edit

Solicitud y respuesta:

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}

Notificación (sin respuesta y sin id):

--> {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5]}

Error de análisis:

--> {"jsonrpc": "2.0", "method": "subtract", "params":
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}

Solicitud no válida:

--> {"jsonrpc": "2.0", "method": 1, "params": "bar"}
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}

Método no encontrado:

--> {"jsonrpc": "2.0", "method": "foobar", "id": 1}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": 1}

Parámetros no válidos:

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42}, "id": 2}
<-- {"jsonrpc": "2.0", "error": {"code": -32602, "message": "Invalid params", "data": "Missing required parameter: subtrahend"}, "id": 2}

Error interno:

--> {"jsonrpc": "2.0", "method": "getData", "params": [], "id": 4}
<-- {"jsonrpc": "2.0", "error": {"code": -32603, "message": "Internal error"}, "id": 4}

Solicitud por lotes con errores:

--> [
      {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1},
      {"jsonrpc": "2.0", "method": "foobar", "id": 2},
      {"foo": "bar"}
    ]
<-- [
      {"jsonrpc": "2.0", "result": 19, "id": 1},
      {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": 2},
      {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}
    ]

Versión 1.1 (borrador de trabajo)#edit

Solicitud y respuesta:

--> {"version": "1.1", "method": "confirmFruitPurchase", "params": [["apple", "orange", "mangoes"], 1.123], "id": "194521489"}
<-- {"version": "1.1", "result": "done", "error": null, "id": "194521489"}

Versión 1.0#edit

Solicitud y respuesta:

--> {"method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
<-- {"result": "Hello JSON-RPC", "error": null, "id": 1}

• gRPC: protocolo RPC binario multiplataforma.
• SOAP: un protocolo de mensajería.
• JSON-WSP: un protocolo inspirado en JSON-RPC con una especificación de descripción de servicios.
• Model Context Protocol: utiliza JSON-RPC para integrar agentes de IA con herramientas externas.^[7]​

1. «specification - JSON-RPC - Trac». Archivado desde el original el 17 de mayo de 2008. Consultado el 14 de mayo de 2008.
2. «JSON-RPC 2.0 Specification». «id: An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null and Numbers SHOULD NOT contain fractional parts».
3. «JSON-RPC 2.0 Specification». «A Notification is a Request object without an "id" member. A Request object that is a Notification signifies the Client's lack of interest in the corresponding Response object, and as such no Response object needs to be returned to the client. The Server MUST NOT reply to a Notification, including those that are within a batch request. Notifications are not confirmable by definition, since they do not have a Response object to be returned. As such, the Client would not be aware of any errors (like e.g. "Invalid params", "Internal error").»
4. «JSON-RPC 2.0 Specification». «result: This member is REQUIRED on success. This member MUST NOT exist if there was an error invoking the method. The value of this member is determined by the method invoked on the Server.»
5. «JSON-RPC 2.0 Specification». «error: This member is REQUIRED on error. This member MUST NOT exist if there was no error triggered during invocation. The value for this member MUST be an Object as defined in section 5.1.»
6. «JSON-RPC 2.0 Specification». «Error object: When a rpc call encounters an error, the Response Object MUST contain the error member with a value that is an Object with the following members: (code) - A Number that indicates the error type that occurred. This MUST be an integer. (message) - A String providing a short description of the error. The message SHOULD be limited to a concise single sentence. (data) - A Primitive or Structured value that contains additional information about the error. This may be omitted. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.).»
7. «Architecture overview». modelcontextprotocol.io.

• Esta obra contiene una traducción total derivada de «JSON-RPC» de Wikipedia en inglés, concretamente de esta versión del 21 de octubre de 2026, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.

• Sitio web oficial
• Grupo de Google de JSON-RPC: debate sobre temas del protocolo y relacionados.
• Especificaciones de JSON-RPC, enlaces, etc.
• Transporte HTTP: descripción para JSON-RPC 2.
• Especificación OpenRPC: formato de descripción de servicios para JSON-RPC (el equivalente de OpenAPI para JSON-RPC).
• JSend: una especificación similar que define únicamente el formato de las respuestas.

• Datos: Q1164443

1. ^ «specification - JSON-RPC - Trac». Archivado desde el original el 17 de mayo de 2008. Consultado el 14 de mayo de 2008.
2. ^ «JSON-RPC 2.0 Specification». «id: An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null and Numbers SHOULD NOT contain fractional parts».
3. ^ «JSON-RPC 2.0 Specification». «A Notification is a Request object without an "id" member. A Request object that is a Notification signifies the Client's lack of interest in the corresponding Response object, and as such no Response object needs to be returned to the client. The Server MUST NOT reply to a Notification, including those that are within a batch request. Notifications are not confirmable by definition, since they do not have a Response object to be returned. As such, the Client would not be aware of any errors (like e.g. "Invalid params", "Internal error").»
4. ^ «JSON-RPC 2.0 Specification». «result: This member is REQUIRED on success. This member MUST NOT exist if there was an error invoking the method. The value of this member is determined by the method invoked on the Server.»
5. ^ «JSON-RPC 2.0 Specification». «error: This member is REQUIRED on error. This member MUST NOT exist if there was no error triggered during invocation. The value for this member MUST be an Object as defined in section 5.1.»
6. ^ «JSON-RPC 2.0 Specification». «Error object: When a rpc call encounters an error, the Response Object MUST contain the error member with a value that is an Object with the following members: (code) - A Number that indicates the error type that occurred. This MUST be an integer. (message) - A String providing a short description of the error. The message SHOULD be limited to a concise single sentence. (data) - A Primitive or Structured value that contains additional information about the error. This may be omitted. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.).»
7. ^ «Architecture overview». modelcontextprotocol.io.