[转载] SON-RPC 2.0 规范(中文版)

原文: http://wiki.geekdream.com/Specification/json-rpc_2.0.html

restful api泛滥, 正好配合jsonrpc规范.

Table of Contents

1.概述

JSON-RPC是一个无状态且轻量级的远程过程调用(RPC)协议。 本规范主要定义了一些数据结构及其相关的处理规则。它允许运行在基于socket,http等诸多不同消息传输环境的同一进程中。其使用JSONRFC 4627)作为数据格式。

它为简单而生!

2.约定

文档中关键字"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"和 "OPTIONAL" 将在RFC 2119 中得到详细的解释及描述。

由于JSON-RPC使用JSON,它具有与其相同的类型系统(见http://www.json.orgRFC 4627)。JSON可以表示四个基本类型(String、Numbers、Booleans和Null)和两个结构化类型(Objects和Arrays)。 规范中,术语“Primitive”标记那4种原始类型,“Structured”标记两种结构化类型。任何时候文档涉及JSON数据类型,第一个字母都必须大写:Object,Array,String,Number,Boolean,Null。包括True和False也要大写。

在客户端与任何被匹配到的服务端之间交换的所有成员名字应是区分大小写的。 函数、方法、过程都可以认为是可以互换的。

客户端被定义为请求对象的来源及响应对象的处理程序。

服务端被定义为响应对象的起源和请求对象的处理程序。

该规范的一种实现为可以轻而易举的填补这两个角色,即使是在同一时间,同一客户端或其他不相同的客户端。 该规范不涉及复杂层。

3.兼容性

JSON-RPC 2.0 的请求对象和响应对象可能无法在现用的JSON-RPC 1.0 客户端或服务端工作,然而我们可以很容易在两个版本间区分出2.0,总会包含一个成员命名为 “jsonrpc” 且值为“2.0”, 而1.0版本是不包含的。大部分的2.0实现应该考虑尝试处理1.0的对象,即使不是对等的也应给其相关提示。

4.请求对象

发送一个请求对象至服务端代表一个rpc调用, 一个请求对象包含下列成员:

jsonrpc

指定JSON-RPC协议版本的字符串,必须准确写为“2.0”

method

包含所要调用方法名称的字符串,以rpc开头的方法名,用英文句号(U+002E or ASCII 46)连接的为预留给rpc内部的方法名及扩展名,且不能在其他地方使用。

params

调用方法所需要的结构化参数值,该成员参数可以被省略。

id

已建立客户端的唯一标识id,值必须包含一个字符串、数值或NULL空值。如果不包含该成员则被认定为是一个通知。该值一般不为NULL[1],若为数值则不应该包含小数[2]

服务端必须回答相同的值如果包含在响应对象。 这个成员用来两个对象之间的关联上下文。

[1] 在请求对象中不建议使用NULL作为id值,因为该规范将使用空值认定为未知id的请求。另外,由于JSON-RPC 1.0 的通知使用了空值,这可能引起处理上的混淆。

[2] 使用小数是不确定性的,因为许多十进制小数不能精准的表达为二进制小数。

4.1通知

没有包含“id”成员的请求对象为通知, 作为通知的请求对象表明客户端对相应的响应对象并不感兴趣,本身也没有响应对象需要返回给客户端。服务端必须不回复一个通知,包含那些批量请求中的。

由于通知没有返回的响应对象,所以通知不确定是否被定义。同样,客户端不会意识到任何错误(例如参数缺省,内部错误)。

4.2参数结构

rpc调用如果存在参数则必须为基本类型或结构化类型的参数值,要么为索引数组,要么为关联数组对象。

  • 索引:参数必须为数组,并包含与服务端预期顺序一致的参数值。
  • 关联名称:参数必须为对象,并包含与服务端相匹配的参数成员名称。没有在预期中的成员名称可能会引起错误。名称必须完全匹配,包括方法的预期参数名以及大小写。

5.响应对象

当发起一个rpc调用时,除通知之外,服务端都必须回复响应。响应表示为一个JSON对象,使用以下成员:

jsonrpc

指定JSON-RPC协议版本的字符串,必须准确写为“2.0”

result

该成员在成功时必须包含。

当调用方法引起错误时必须不包含该成员。

服务端中的被调用方法决定了该成员的值。

error

该成员在失败是必须包含。

当没有引起错误的时必须不包含该成员。

该成员参数值必须为5.1中定义的对象。

id

该成员必须包含。

该成员值必须于请求对象中的id成员值一致。

若在检查请求对象id时错误(例如参数错误或无效请求),则该值必须为空值。

响应对象必须包含result或error成员,但两个成员必须不能同时包含。

5.1错误对象

当一个rpc调用遇到错误时,返回的响应对象必须包含错误成员参数,并且为带有下列成员参数的对象:

code

使用数值表示该异常的错误类型。 必须为整数。

message

对该错误的简单描述字符串。 该描述应尽量限定在简短的一句话。

data

包含关于错误附加信息的基本类型或结构化类型。该成员可忽略。 该成员值由服务端定义(例如详细的错误信息,嵌套的错误等)。

-32768至-32000为保留的预定义错误代码。在该范围内的错误代码不能被明确定义,保留下列以供将来使用。错误代码基本与XML-RPC建议的一样,url: http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

code message meaning
-32700 Parse error语法解析错误 服务端接收到无效的json。该错误发送于服务器尝试解析json文本
-32600 Invalid Request无效请求 发送的json不是一个有效的请求对象。
-32601 Method not found找不到方法 该方法不存在或无效
-32602 Invalid params无效的参数 无效的方法参数。
-32603 Internal error内部错误 JSON-RPC内部错误。
-32000 to -32099 Server error服务端错误 预留用于自定义的服务器错误。

除此之外剩余的错误类型代码可供应用程序作为自定义错误。

6.批量调用

当需要同时发送多个请求对象时,客户端可以发送一个包含所有请求对象的数组。

当批量调用的所有请求对象处理完成时,服务端则需要返回一个包含相对应的响应对象数组。每个响应对象都应对应每个请求对象,除非是通知的请求对象。服务端可以并发的,以任意顺序和任意宽度的并行性来处理这些批量调用。

这些相应的响应对象可以任意顺序的包含在返回的数组中,而客户端应该是基于各个响应对象中的id成员来匹配对应的请求对象。

若批量调用的rpc操作本身非一个有效json或一个至少包含一个值的数组,则服务端返回的将单单是一个响应对象而非数组。若批量调用没有需要返回的响应对象,则服务端不需要返回任何结果且必须不能返回一个空数组给客户端。

7.示例

Syntax:

--> data sent to Server
<-- data sent to Client

带索引数组参数的rpc调用:

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

--> {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2}
<-- {"jsonrpc": "2.0", "result": -19, "id": 2}

带关联数组参数的rpc调用:

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

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

通知:

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

不包含调用方法的rpc调用:

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

包含无效json的rpc调用:

--> {"jsonrpc": "2.0", "method": "foobar, "params": "bar", "baz]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}

包含无效请求对象的rpc调用:

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

包含无效json的rpc批量调用:

--> [
        {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
        {"jsonrpc": "2.0", "method"
    ]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}

包含空数组的rpc调用:

--> []
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}

非空且无效的rpc批量调用:

--> [1]
<-- [
    {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}
    ]

无效的rpc批量调用:

--> [1,2,3]
<-- [
    {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
    {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
    {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}
    ]

rpc批量调用:

--> [
    {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
    {"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
    {"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
    {"foo": "boo"},
    {"jsonrpc": "2.0", "method": "foo.get", "params": {"name": "myself"}, "id": "5"},
    {"jsonrpc": "2.0", "method": "get_data", "id": "9"}
    ]
<-- [
    {"jsonrpc": "2.0", "result": 7, "id": "1"},
    {"jsonrpc": "2.0", "result": 19, "id": "2"},
    {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
    {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "5"},
    {"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
    ]

所有都为通知的rpc批量调用:

--> [
    {"jsonrpc": "2.0", "method": "notify_sum", "params": [1,2,4]},
    {"jsonrpc": "2.0", "method": "notify_hello", "params": [7]}
]

<-- //Nothing is returned for all notification batches

7.扩展

以rpc开头的方法名预留作为系统扩展,且必须不能用于其他地方。每个系统扩展都应该有相关规范文档,所有系统扩展都应是可选的。

时间: 2024-10-08 15:32:39

[转载] SON-RPC 2.0 规范(中文版)的相关文章

(译) JSON-RPC 2.0 规范(中文版)

1.概述 JSON-RPC是一个无状态且轻量级的远程过程调用(RPC)协议. 本规范主要定义了一些数据结构及其相关的处理规则.它允许运行在基于socket,http等诸多不同消息传输环境的同一进程中.其使用JSON(RFC 4627)作为数据格式. 它为简单而生! 2.约定 文档中关键字"MUST"."MUST NOT"."REQUIRED"."SHALL"."SHALL NOT"."SHOULD

【转载】PHP PSR-1 基本代码规范(中文版)

基本代码规范 本篇规范制定了代码基本元素的相关标准, 以确保共享的PHP代码间具有较高程度的技术互通性. 关键词 "必须"("MUST")."一定不可/一定不能"("MUST NOT")."需要"("REQUIRED")."将会"("SHALL")."不会"("SHALL NOT")."应该&quo

JSON-RPC 2.0规范 翻译 中文版

JSON-RPC 2.0规范 起源日期: 2010-03-26(基于2009-05-24的版本) 修正: 2013-01-04 作者: JSON-RPC 工作组 <[email protected]> 1 概述 JSON-RPC是一个无状态的.轻量级的远程过程调用(RPC)协议.本规范主要围绕它的处理方式定义了几个数据结构和规则.这个概念可用于在同一进程中.套接字或HTTP之间.或其他很多消息传递的环境中传输数据.它使用JSON (RFC 4627)作为数据格式. JSON-RPC的设计很简单

DICOM:DICOM3.0标准中文版开源书籍编辑之”github仓库合并“

背景: 作为分布式版本控制系统的代表git和github已经成为大多数开发人员首选版本控制工具.由于其不同与SVN的集中式版本管理,因此在协同工作时的方式略有不同,下面让我们来对比分析一下(这里以本人的DICOM3.0标准中文版开源书籍为例): 合并他人的Github仓库(Merge Other's Repo on Github): 1. 查看当前状态 F:\GitTest\zssuretest\DICOM-Chinese>git status On branch master Your bra

json-rpc 2.0规范解读

JSON-RPC2.0规范由JSON-RPC工作组([email protected])维护,发布于2010-03-26(基于2009-05-24的版本), 最近的更新于2013-01-04. 整体来说,2.0版本的JSON-RPC规范改动的很小,大的改动大概有3点: 参数可以用数组或命名参数 批量请求的细节明确化了 错误处理的机制标准化了 与1.0版本的兼容性 建议2.0规范的实现兼容1.0协议,但是不强制要求,如果不能兼容,建议给出友好提示. 请求和响应报文加了个参数表示协议的版本号:jso

【转载】简历的书写规范(公司怎么看我们的简历)

人事部门是这样阅读简历的 (+15分)如果简历中说到了和工作职位相符的技能超过5次以上. (+8分)如果简历中说到了和工作职位相符的技能3次到5次. (+4分)如果简历中说到了和工作职位相符的技能1次到2次. (+4分)Cover Letter(“求职信”或“自荐信”)提到了招聘人员. (+2分)简历中有Cover Letter(求职信). (-10分)没有提到和职位描述相关的技能. (-15分)没有受过大专教育. 程序员是这样阅读简历的 (+15分)曾经因为好玩而写过操作系统或编译器. (+1

OpenACC2.0标准中文版

OpenACC2.0标准中文版下载地址,请移步这里 昨天晚上睡前突然想到这茬,然后又从网盘里找出自己翻译的版本,上传至CSDN上. 自己应该是2012年2~3月份开始接触的OpenACC,其实自己在看OpenACC1.0标准时就想过去翻译,可是在学校每天可干的事情太多了,自己也就想想而已.所以OpenACC1.0标准中文版的作者是小小河. 2013年5月份,2.0标准正式发布.2013年6月下旬的样子,私底下问过小小河,他还继续翻译不.当时他的答复是事情多,不翻译了. 小小河不翻译,那我就上吧,

json-rpc 1.0规范解读

JSON可能是这个地球上最简单的文本数据格式了,可读.灵活.数据量小,编解码方便.速度快,对Unicode和特殊字符支持的好.对比下XML,就知道额外的各种标签节点需要浪费多少字节数.JSON字符默认都要使用Unicode形式,所有非ACSII字符都可以用\uXXXX表示,而不需要额外的转义.相比之下,XML里需要使用转义或是CDATA(类似HTML里的PRE标签).或是Base64才能表示特殊数据.当然缺点也很明显,比二进制数据结构的数据量大,编解码慢,没有完备的类型系统,表达能力有限. JS

MINA2.0用户手册中文版

MINA2.0用户手册中文版--第一章 MINA2.0入门 MINA2.0用户手册中文版--第二章 第一节 MINA应用程序架构 MINA2.0用户手册中文版--第二章 第二节 TCP服务端实例 MINA2.0用户手册中文版--第二章 第三节 TCP客户端实例 MINA2.0用户手册中文版--第二章 第四节 UDP服务端实例 MINA2.0用户手册中文版--第二章 第五节 UDP客户端实例 MINA2.0用户手册中文版--第三章 第一节 IoService接口简介 MINA2.0用户手册中文版-