什么是 JSON-RPC？消息、方法和错误处理
无抓取的通用抓取 API 检索被允许的公共网页内容，并能在必须遵循 JSON-RPC 的实际响应中渲染 JavaScript。
TL;DR
- JSON-RPC 具有一个精确的协议角色。 JSON-RPC 是一个轻量级的无状态远程过程调用协议，将方法调用、结果和错误表示为 JSON 对象。
- JSON-RPC 必须在正确的层次读取。 传输、表示、浏览器策略和应用程序授权仍然是独立的关注点。
- 中介可以改变应用程序观察到的内容。 网关、缓存、浏览器默认设置和客户端库可以在源字节和解析数据之间添加处理。
- 验证需要内容证据。 单独的状态或字段并不能证明预期的公共表示到达。
- 安全性取决于范围和验证。 协议语法从不授予访问资源或信任调用者提供的值的权限。
什么是 JSON-RPC？
JSON-RPC 是一个轻量级的无状态远程过程调用协议，将方法调用、结果和错误表示为 JSON 对象。版本 2.0 定义消息成员和处理规则，但不要求使用 HTTP 或任何其他特定传输。客户端指定一个方法，选择性地提供结构化参数，并使用 ID 来关联响应与其请求。
有用的定义包括机制及其边界。JSON-RPC 影响交换的特定部分，而相邻的责任仍然由 HTTP、浏览器、所选传输、应用程序或服务器的数据模型承担。保持这些层次的独立性使错误报告可重现，并防止配置更改被误认为访问控制决策。
对于 API 开发人员，第一个问题是由谁创建值或行为。下一个问题是由谁解释它。最后一个问题是哪个可观察的结果证明了解释有效。这三个答案将词汇术语转变为可测试的接口合同。
JSON-RPC 消息如何形成对话
请求对象包含 jsonrpc 设置为 2.0、一个方法字符串、可选参数，通常还有一个 id。参数可以是位置参数的数组或命名参数的对象。命名参数减少了对顺序的意外依赖，但它们的名称必须与服务器合同完全匹配。
成功的响应重复请求 ID 并包含一个结果成员。失败的响应重复 ID 并包含一个具有数字代码和消息的错误对象，以及可选数据。结果和错误是替代的；响应不应声称两种结果。
通知省略 ID 成员，请求服务器执行工作而不发送响应。缺少响应是协议的一部分，因此通知无法确认成功或向其发送方暴露应用程序错误。仅在接受这种不确定性时使用它。
批处理是包含多个请求或通知对象的 JSON 数组。服务器可以按照自己的顺序处理它们，响应顺序不必与请求顺序匹配。因此，客户端根据 ID 而不是数组位置关联批处理结果。
JSON-RPC 2.0 对象中的成员
以下术语区分通常合并为一个标签的组件。将它们视为参与者之间的接口，而不是网络跟踪中的装饰。
jsonrpc
协议版本标记。JSON-RPC 2.0 消息使用字符串值 2.0，以便与旧版本区分。
method
远程过程名称。以 rpc. 开头的名称保留用于协议扩展，不应用于普通应用程序方法。
params
可选的结构化参数，可以通过数组中的位置或对象中的名称提供。
id
一个字符串、数字或空值，用于将响应与请求匹配。省略 ID 会创建一个通知。
result
由方法返回的成功值。其模式属于应用程序的方法合同。
error
带有代码和消息成员的失败对象，以及可以携带结构化诊断细节的可选数据。
为什么 JSON-RPC 在网页数据收集中的重要性
JSON-RPC 可以改变到达的字节、这些字节如何被解释或浏览器代码是否可以观察到结果。收集工作流程应该在更改工具之前找到该影响。记录请求的 URL、最终 URL、响应状态、表示类型、相关协议字段和一个预期的内容标记。该紧凑记录区分正确页面与访问消息、同意屏幕、重定向目标、空应用程序外壳或不兼容编码。
当所需数据存在于开放的服务器渲染的响应中时，直接 HTTP 是最简单的获取路径。当批准的内容依赖于 JavaScript 执行、浏览器管理的状态、导航或浏览器安全策略时，浏览器变得相关。这两条路径不应强制看起来相同：浏览器根据平台规则管理 cookies、压缩、重定向、CORS 和存储，而直接客户端暴露了不同的默认设置。
会话连续性在一个响应为下一个请求建立状态时很重要。保持在一个有界的客户端上下文内的授权序列，保存所需的区域和网络来源，并避免混合来自无关工作的状态。代理更改网络来源；它不会复制头部、解码表示、执行脚本或授予访问受限内容的权限。
解析仅在表示验证后开始。在提取字段之前，确认最终主机、可用的规范身份、媒体类型、解码状态和所需的业务标记。这个顺序可以防止解析器将错误文档变成看似技术上成功的空记录。
中介值得明确关注。内容传递网络可以选择编码变体，网关可以回答OPTIONS，缓存可以重用协商的响应，应用服务器可以设置cookie或授权字段。仅比较应用代码与最终页面输出跳过了可能作出决策的层。
没有垃圾的通用抓取API在团队需要管理允许的公共内容检索时相关，包括JavaScript渲染的页面。获取合同仍应定义目标、允许字段、预期表示、接受标记和停止条件。产品能力不能替代源条款、隐私审查或应用级验证。
当JSON-RPC适合时
当JSON-RPC改变具体产品行为、兼容性要求或诊断决策时，它在架构中占有一席之地。这些用例首先描述工作，然后描述协议特性。
命令导向API
方法名称可以表达不完全映射到资源创建、读取、更新或删除的操作。
钱包和节点接口
一个紧凑的请求信封适用于公开一组稳定命名操作的软件。
编辑器和语言工具
对等方可以通过持久通道交换方法和通知，同时共享一种消息模型。
嵌入式控制平面
该协议可以在选择的流或消息传输上运行，而不重新定义其JSON对象形状。
可批量读取操作
当服务器和传输支持批量时，可以将独立的方法调用分组，并且相关ID是可靠的。
小型互操作客户端
客户端可以实施具有普通JSON支持的核心协议，前提是方法模式单独记录。
JSON-RPC与REST风格HTTP和gRPC的比较
JSON-RPC将API集中在方法调用上，而REST风格的HTTP则将其集中在资源、表示和标准方法语义上。gRPC也建模方法，但增加了一个模式工具链和一个面向二进制的传输堆栈。当紧凑的方法信封很重要且传输必须保持单独选择时，JSON-RPC是有吸引力的。
| 维度 | JSON-RPC | 相关概念或替代品 |
|---|---|---|
| 主要抽象 | 命名远程方法 | 通过URI寻址的资源 |
| 信封 | 定义的JSON请求和响应对象 | HTTP请求和表示约定 |
| 运输 | 不在规范中规定 | HTTP是协议表面 |
| 错误 | JSON-RPC错误对象和代码 | HTTP状态加响应表示 |
| 单向消息 | 没有id的通知 | 特定于应用的HTTP行为 |
比较只有在保留层边界的情况下才有用。机制可以在一个请求中共存，替换一个并不会自动替换另一个。以输入、可观察输出、失败状态和所有权的术语记录所选行为。
导致模糊结果的JSON-RPC错误
- 将通知用于重要写入。 通知没有响应，因此调用者无法知道验证或执行是否失败。
- 按位置匹配批量响应。 规范允许以任何顺序响应。将每个结果与请求ID匹配。
- 在调用活动时重用ID。 重复的活动ID使相关性模糊，尤其是在持久连接上。
- 将HTTP状态视为方法结果。 当JSON-RPC在HTTP上运行时，传输状态和JSON-RPC结果描述不同的层。检查两者。
- 让方法架构隐含。 信封定义协议成员，而不是每个应用方法的类型和规则。发布一个单独的方法合同。
- 返回内部异常文本。 错误数据可能会暴露堆栈细节或机密。将失败映射到稳定的公共代码和批准的诊断字段上。
去掉对库或浏览器自动执行的假设之后，大多数失败变得更容易诊断。捕获最小的跟踪，编辑机密，并一次更改一个受控变量。目标是返回表示的稳定解释，而不是一系列无关的头部调整。
一个JSON-RPC审查序列
这个序列作为发射前的设计审查以及行为变化后的生产诊断工作。它保持协议证据与应用结果相连。
- 盘点每个方法并决定其参数是位置参数还是命名参数；不要在一个API内部随意混合约定。
- 在实现处理程序之前定义每个方法的结果架构和公共错误代码。
- 选择一个在活动调用中保持唯一并且在每个客户端语言中有效的ID生成规则。
- 在日志和测试中分开传输失败、格式错误的JSON、无效的JSON-RPC对象、方法错误和成功的结果。
- 测试通知时不期望响应，包括放在批处理中的通知。
- 在测试中随机打乱批处理响应顺序，以证明客户端是通过ID而不是数组索引进行关联的。
- 记录身份验证、授权、消息大小限制和传输框架，因为JSON-RPC本身并未定义它们。
通过保存一个小的接受样本和一个拒绝样本，并遵循相同的编辑规则来完成审查。未来的变更可以与已知页面身份、预期字段和解码内容进行对比，而不仅仅是内存或屏幕截图。
JSON信封外的安全边界
JSON-RPC不验证调用者，不加密流量，不限制消息大小，也不授权方法。这些控制属于所选的传输和应用程序。WebSocket部署、HTTP部署和本地流可以使用相同的JSON-RPC对象，但拥有不同的威胁模型。
方法名称和参数是不可信的输入。针对允许列表验证方法，针对方法架构验证参数，并在建立调用者身份后应用授权。一个语法上有效的JSON-RPC请求并不意味着有权限执行操作。
错误响应应帮助客户端行动，而不暴露实施细节。稳定的公共代码、简洁的消息和有限的结构化数据比原始异常更容易监控。日志可以保留一个内部关联值，而无需复制完整的敏感参数对象。
定义JSON-RPC的标准
JSON-RPC 2.0规范 定义请求、响应、通知和批处理。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在所选客户端和部署中观察。
JSON数据交换标准 定义了协议所携带的JSON语法。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在所选客户端和部署中观察。
OpenRPC规范 提供了一种机器可读的JSON-RPC API描述格式。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在所选客户端和部署中观察。
WebSocket协议 是JSON-RPC消息的一种可能的持久传输。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在所选客户端和部署中观察。
JSON-RPC要点
JSON-RPC是一个小规模的方法调用协议，不是一个完整的API平台；它的简单性在团队明确定义方法架构、传输行为、安全性和围绕信封的可观察性时效果最佳。
将该规则放入验收测试中。说明哪个参与者发送信号，哪个参与者解释信号，哪些中介可以改变路径，以及哪个内容标记证明成功。这使JSON-RPC成为可观察系统的一部分，而不是在失败后附加的标签。
准备验证公共网页响应吗？
使用Scrapeless Universal Scraping API检索经过批准的公共内容并检查本指南中描述的表示合同。
今天注册并获取 $5的免费信用 — 不需要信用卡.
领取您的$5信用→常见问题
JSON-RPC与HTTP相关吗？
不。JSON-RPC 2.0是与传输无关的，可以通过HTTP、WebSocket、本地流或其他消息通道传输。每个部署必须单独定义框架、身份验证和连接行为。
是什么使得JSON-RPC请求成为通知？
当JSON-RPC请求省略id成员时，它就是一个通知。服务器不得对该消息返回响应，即使通知出现在批处理中。
JSON-RPC的批处理响应可以以不同的顺序到达吗？
可以。服务器可以以其选择的顺序处理批条目并以其他顺序返回响应对象。客户端必须使用每个ID将响应与其请求关联。
JSON-RPC错误与HTTP错误有何不同？
JSON-RPC错误报告解析或调用远程方法的结果，而HTTP错误报告传输级HTTP结果。HTTP部署应观察这两个层面，而不是将它们合并为一个状态。
JSON-RPC定义身份验证吗？
不。JSON-RPC不定义调用者身份验证或授权。周围的传输和应用程序必须建立身份、保护凭证，并检查每个方法的权限。