当前位置：首页 > news >正文

Odoo API 集成：XML-RPC 与 JSON-RPC 的比较

news 来源：原创 2025/6/26 9:42:46

在将外部应用程序与 Odoo 集成的过程中，开发者面临一个关键的战略抉择：在平台提供的两种原生远程过程调用 (RPC) 协议中，应选择哪一种？这一决策不仅影响开发效率，更深远地关系到集成的性能、可维护性以及未来的可扩展性。

首先必须明确，Odoo 的核心外部 API 是基于 RPC 架构的，它通过两种截然不同的协议对外暴露：XML-RPC 和 JSON-RPC。这与那些以 REST (表述性状态转移) 为首选架构的系统形成了鲜明对比。尽管社区和第三方供应商提供了能够为 Odoo 包装一层 RESTful 接口的模块，这些模块提供了面向资源的架构风格，但它们并非 Odoo 的原生解决方案。本文将聚焦于 Odoo 开箱即用、官方支持的 RPC 方法。这些原生方法在直接调用对象关系映射 (ORM) 层的丰富功能方面，拥有无与伦比的强大能力与灵活性。

本文旨在提供一份权威且基于证据的深度分析，以指导开发者在 XML-RPC 和 JSON-RPC 之间做出明智选择。文的核心论点是：尽管两种协议目前均可使用，但对于 Odoo 18 的新开发项目而言，JSON-RPC 代表了更现代化、更高效且面向未来的技术路径；而 XML-RPC 则主要在特定的遗留系统对接场景中保留其价值。

第一节：XML-RPC 协议：久经考验的“老将”

XML-RPC 作为 Odoo (前身为 OpenERP) 早期的主要集成协议，凭借其标准化、跨语言支持和相对简单的特性，在 Odoo 的发展历程中扮演了重要角色。然而，随着技术演进，其设计中的一些固有特性在现代应用场景下也显现出局限性。

架构概况

XML-RPC 是一种标准化的远程过程调用协议，它使用 XML 对调用和响应进行编码，并通过 HTTP 作为其传输机制。其设计的核心在于简洁和广泛的兼容性，这使其在早期成为各种系统间通信的流行选择。

在 Odoo 中，XML-RPC 的交互依赖于两个明确定义的端点 (Endpoint)：

/xmlrpc/2/common：此端点用于处理无需身份验证的“元”调用。其最核心的功能是用户身份验证 (authenticate)，此外还可用于获取 Odoo 服务器版本信息等操作。
/xmlrpc/2/object：这是所有已认证数据操作的主要端点。客户端通过调用此端点上的 execute_kw 函数，来执行 Odoo 模型上的各种方法，从而实现对业务数据的增删改查 (CRUD) 等所有操作。

认证与会话管理

使用 Python 与 Odoo XML-RPC 接口交互时，标准库 xmlrpc.client 是首选工具。整个认证流程分为清晰的几个步骤：

导入库：首先，导入 xmlrpc.client 模块。
定义连接参数：设置 Odoo 服务器的 URL、目标数据库名称、用户名以及密码或 API 密钥。
认证并获取用户ID (uid)：创建指向 /xmlrpc/2/common 端点的 ServerProxy 实例。调用其 authenticate 方法，传入连接参数。成功后，服务器将返回一个整数类型的用户 ID (uid)，此 uid 相当于后续所有请求的会话标识符。
准备数据操作：创建第二个指向 /xmlrpc/2/object 端点的 ServerProxy 实例。这个实例将用于执行所有后续的业务逻辑调用。

以下是完整的认证示例代码：

import xmlrpc.client# 1. 定义连接参数
url = "http://your_odoo_instance.com:8069"
db = "your_database_name"
username = "your_login_email"
password = "your_password_or_api_key"# 2. 连接 'common' 端点进行认证
common = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/common')
try:uid = common.authenticate(db, username, password, {})print(f"认证成功，用户 UID: {uid}")
except xmlrpc.client.Fault as err:print(f"认证失败: {err}")uid = None# 3. 连接 'object' 端点准备执行操作
if uid:models = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/object')# 后续所有模型方法调用都将使用 'models' 这个代理对象

使用 `execute_kw` 掌握 ORM 操作

execute_kw 是 Odoo XML-RPC 接口的核心。这一个函数构成了与 Odoo ORM 交互的唯一入口点，几乎所有的数据操作都通过它完成。其函数签名如下：

execute_kw(database, uid, password, model_name, method_name, positional_args, keyword_args)

model_name: 目标模型的名称 (例如 'res.partner')。
method_name: 要调用的 ORM 方法名称 (例如 'search_read', 'create', 'write')。
positional_args: 一个列表，包含按位置传递给方法的参数。
keyword_args: 一个字典，包含按关键字传递给方法的参数 (可选)。

通过 execute_kw，开发者可以调用 Odoo 模型上任何公开的方法，包括但不限于 search, read, create, write, unlink, search_count 和 fields_get 等，其能力与在 Odoo 服务器端编写 Python 代码几乎等同。

实践应用：CRUD 示例

以下代码片段演示了如何使用 XML-RPC 对客户模型 (res.partner) 进行标准的增删改查操作。

创建 (Create)

创建一个新的合作伙伴记录。

# 假设 'models', 'db', 'uid', 'password' 已被初始化
new_partner_data = {'name': 'New Partner via XML-RPC','company_type': 'person','email': 'xmlrpc.partner@example.com','phone': '1234567890',
}
try:partner_id = models.execute_kw(db, uid, password,'res.partner','create',[new_partner_data])print(f"成功创建合作伙伴，ID: {partner_id}")
except xmlrpc.client.Fault as err:print(f"创建失败: {err}")

读取 (Read)

使用 search_read 方法，它能在一个请求中完成记录的搜索和读取，效率极高。

# 搜索所有类型为“公司”的客户，并读取其名称和邮箱
domain_filter =]]
fields_to_read = ['name', 'email']
try:partners = models.execute_kw(db, uid, password,'res.partner','search_read',domain_filter,{'fields': fields_to_read, 'limit': 5})print("查询到的公司客户:")for partner in partners:print(f"  - ID: {partner['id']}, 名称: {partner['name']}, 邮箱: {partner.get('email', 'N/A')}")
except xmlrpc.client.Fault as err:print(f"查询失败: {err}")

更新 (Update)

使用 write 方法更新一个或多个记录。

# 更新 ID 为 'partner_id' 的合作伙伴的电话号码
# 'partner_id' 应为上一步创建或已知存在的 ID
if 'partner_id' in locals():try:models.execute_kw(db, uid, password,'res.partner','write',[[partner_id], {'phone': '0987654321'}])print(f"成功更新合作伙伴 ID: {partner_id}")except xmlrpc.client.Fault as err:print(f"更新失败: {err}")

删除 (Delete)

使用 unlink 方法删除一个或多个记录。

# 删除 ID 为 'partner_id' 的合作伙伴
if 'partner_id' in locals():try:models.execute_kw(db, uid, password,'res.partner','unlink',[[partner_id]])print(f"成功删除合作伙伴 ID: {partner_id}")except xmlrpc.client.Fault as err:print(f"删除失败: {err}")

高级注意事项

数据类型处理

通过 XML-RPC 传输数据时，特定 Odoo 字段类型需要进行格式转换，这是集成开发中常见的错误来源：

日期 (Date) 和日期时间 (Datetime)：必须作为字符串以 ISO 8601 格式发送。日期格式为 'YYYY-MM-DD'，日期时间格式为 'YYYY-MM-DD HH:MM:SS'。
二进制 (Binary)：如图片或附件，必须先进行 Base64 编码，然后作为字符串传输。
关系字段 (Many2one, One2many, Many2many)：对于 Many2one 字段，通常传递关联记录的整数 ID 即可。对于 x2many 字段的写入操作，则需要使用一套特殊的命令三元组格式，例如 (0, 0, {values}) 用于创建新记录。

错误处理

XML-RPC 的错误响应结构化程度较低。当调用失败时，服务器返回一个 XML <fault> 元素，其中包含 faultCode (错误代码) 和 faultString (错误信息) 。一个值得注意的特点是，当 Odoo 内部发生未被捕获的异常时，faultString 中可能会包含完整的 Python 堆栈跟踪信息。这对于开发者调试极为有用，但如果直接暴露给最终用户或记录在不安全的日志中，则可能构成安全风险。

潜在影响分析

在评估 XML-RPC 时，必须认识到其历史背景和技术特性所带来的深层影响。

首先，存在显著的“文档偏见”和遗留足迹。由于 Odoo 的悠久历史，XML-RPC 作为其多年的主要 API，积累了大量的官方文档、社区教程、论坛问答和第三方库。这种历史沉淀导致新开发者在搜索“Odoo API”时，极有可能首先接触到的是关于 XML-RPC 的内容。这会产生一种误导，让他们以为 XML-RPC 是当前推荐或唯一的标准方法，而事实并非如此。这种现象的根源在于，早期的技术选择塑造了长期的信息生态，而这种生态的惯性往往滞后于技术本身的演进。

其次，XML 固有的“冗余税”对性能造成了持续的负面影响。XML 的语法要求每个数据元素都必须由开始标签和结束标签包裹 (例如 <name>John</name>)，这与 JSON 简洁的键值对格式 ("name": "John") 相比，天生就更为冗长。有基准测试表明，同样的数据结构，XML 格式的体积比 JSON 大约 13%，并且解析速度更慢。对于需要进行大量 API 调用的高频集成场景，这种“冗余税”会不断累积，导致更高的网络带宽消耗和更长的处理延迟，最终影响整个应用的响应性能和用户体验。

第二节：JSON-RPC 协议：现代化的标准

JSON-RPC 作为 Odoo 的现代化 API 协议，不仅在技术上更符合当代 Web 开发的趋势，更重要的是，它深度整合在 Odoo 平台的核心运作之中，是 Odoo 自身 Web 客户端与后端通信的基石。

架构概况

JSON-RPC 是一种轻量级的远程过程调用协议，它使用 JSON 作为数据交换格式，并遵循 JSON-RPC 2.0 规范。其在 Odoo 中最显著的特点是，Odoo 官方的 Web 客户端就是通过 JSON-RPC 与服务器后端进行所有交互的。这意味着 JSON-RPC 是 Odoo 内部事实上的“官方”通信协议。

其架构上的优势体现在简洁性上：

单一端点：与 XML-RPC 不同，JSON-RPC 只有一个统一的端点，通常是 /jsonrpc。无论是身份验证还是数据操作，所有请求都发送到这同一个 URL，极大地简化了客户端的配置。
标准化的请求结构：每个请求都是一个遵循 JSON-RPC 2.0 规范的 JSON 对象，包含以下关键字段：
- jsonrpc: 固定为字符串 "2.0"。
- method: 对于 Odoo 的主分发器，此值通常固定为 "call"。
- params: 一个 JSON 对象，包含了实际的调用细节，如服务名、方法名和参数。
- id: 一个由客户端生成的唯一标识符 (可以是字符串或数字)，用于将响应与请求进行匹配，支持异步调用。

认证与会话管理

对于 Python 开发者而言，使用广受欢迎的 requests 库与 JSON-RPC 交互是比标准库 urllib 更为现代和直观的选择。认证过程如下：

导入库：导入 requests 和 json 库。
定义连接参数：设置 Odoo 实例的 URL、数据库、用户名和密码。
构建认证载荷：构造一个 JSON-RPC 请求体。要进行认证，params 对象中的 service 应为 "common"，method 为 "login" 或 "authenticate"。
发送请求并管理会话：使用 requests.post 发送带有 JSON 载荷的请求。Odoo 服务器会在响应的 Set-Cookie 头中返回 session_id。为了简化会话管理，强烈建议使用 requests.Session 对象，它能自动处理和发送 Cookie，使后续调用无需再次手动处理会话信息。认证成功后，用户 uid 会在 JSON 响应体中返回。

以下是使用 requests.Session 的认证示例代码：

import requests
import json# 1. 定义连接参数
url = "http://your_odoo_instance.com/jsonrpc"
db = "your_database_name"
username = "your_login_email"
password = "your_password_or_api_key"# 2. 使用 requests.Session 管理会话
session = requests.Session()
headers = {"Content-Type": "application/json"}# 3. 构建认证请求载荷
auth_payload = {"jsonrpc": "2.0","method": "call","params": {"service": "common","method": "authenticate","args": [db, username, password, {}]},"id": 1
}# 4. 发送认证请求
try:response = session.post(url, data=json.dumps(auth_payload), headers=headers, timeout=10)response.raise_for_status()  # 检查 HTTP 错误result = response.json()if result.get('error'):print(f"认证失败: {result['error']['message']}")uid = Noneelse:uid = result.get('result')print(f"认证成功，用户 UID: {uid}")# session 对象现在已包含 session_id cookie，可用于后续请求
except requests.exceptions.RequestException as e:print(f"网络或HTTP请求错误: {e}")uid = None

使用 `execute_kw` 掌握 ORM 操作

与 XML-RPC 类似，JSON-RPC 也通过 execute_kw 方法调用 ORM 功能。调用的结构被封装在 params 对象中：

service: "object"
method: "execute_kw"
args: 一个列表，其结构与 XML-RPC 的参数完全一致：[db, uid, password, model_name, method_name, positional_args, keyword_args]。

实践应用：CRUD 示例

以下示例展示了如何构造 JSON-RPC 载荷来执行 CRUD 操作。

创建 (Create)

创建一个新的项目记录 (project.project)。

# 假设 'session', 'url', 'headers', 'db', 'uid', 'password' 已被初始化
create_payload = {"jsonrpc": "2.0","method": "call","params": {"service": "object","method": "execute_kw","args":},"id": 2
}
# response = session.post(url, data=json.dumps(create_payload), headers=headers)
# print(response.json())

读取 (Read)

使用 search_read 搜索并读取员工记录 (hr.employee)。

search_read_payload = {"jsonrpc": "2.0","method": "call","params": {"service": "object","method": "execute_kw","args":[db, uid, password,"hr.employee","search_read",{"fields": ["name", "work_email"], "limit": 5}]},"id": 3
}
# response = session.post(url, data=json.dumps(search_read_payload), headers=headers)
# print(response.json())

更新 (Update)

使用 write 方法更新项目名称。

Python

# 'project_id' 是上一步创建或已知的项目ID
update_payload = {"jsonrpc": "2.0","method": "call","params": {"service": "object","method": "execute_kw","args": [db, uid, password,"project.project","write",[[project_id], {'name': 'Updated Project Name'}]},"id": 4
}
# response = session.post(url, data=json.dumps(update_payload), headers=headers)# print(response.json())

删除 (Delete)

使用 unlink 方法删除项目。

delete_payload = {"jsonrpc": "2.0","method": "call","params": {"service": "object","method": "execute_kw","args": [db, uid, password,"project.project","unlink",[[project_id]]},"id": 5
}
# response = session.post(url, data=json.dumps(delete_payload), headers=headers)# print(response.json())

高级注意事项

数据类型处理

JSON 的数据类型（字符串、数字、布尔值、数组、对象）与 Python 等现代编程语言的内置数据类型有更直接的映射关系，这减少了数据转换的复杂性。例如，数字和布尔值可以直接传输，无需像 XML-RPC 那样全部转换为字符串。日期和日期时间字段仍然建议作为标准格式的字符串进行传输。

错误处理

JSON-RPC 的错误处理机制是其一大优势。当请求失败时，服务器返回一个结构化的 JSON 错误对象，该对象遵循 2.0 规范，包含 code、message 和可选的 data 字段。这种标准化的结构使得客户端可以轻松地以编程方式解析错误，实现更精细和自动化的错误处理逻辑，远胜于 XML-RPC 简单的

faultString。

潜在影响分析

选择 JSON-RPC 不仅仅是技术偏好，更是与 Odoo 平台核心架构对齐的战略决策。

首先，JSON-RPC 是 Odoo 的“活的”规范。由于 Odoo 自身的 Web 客户端完全依赖 JSON-RPC 进行前后端通信，这意味着 Odoo 核心开发团队必须确保此 API 的稳定性、性能和功能的完整性。任何新的 ORM 功能或核心改动，都将第一时间在 JSON-RPC 接口上得到支持和验证。因此，使用 JSON-RPC 的开发者实际上是在利用 Odoo 内部的通信主干道，这最大限度地降低了遇到 API 功能滞后或支持不佳的风险。它不是一个事后添加的外部接口，而是 Odoo 平台运作的心脏。

其次，对于 Web 开发者而言，JSON-RPC 提供了更低的认知门槛。现代 Web 开发生态系统几乎完全由使用 JSON 的 REST API 主导。尽管 JSON-RPC 并非 RESTful，但它共享了相同的数据格式 (JSON) 和传输协议 (HTTP POST)，其请求-响应模式对于任何有现代 API 开发经验的工程师来说都非常熟悉。相比之下，XML-RPC 要求开发者适应一种不同的数据格式和稍显繁琐的双端点认证模型。这种熟悉度使得新开发者能更快地理解和集成 Odoo，缩短了学习曲线和开发周期。

最后，种种迹象表明，XML-RPC 正在经历“非官方的弃用”过程。虽然 Odoo 为了保持向后兼容性而继续支持 XML-RPC，并且没有正式宣布停止服务的计划，但平台的开发重心已明显转移。Odoo 官方的最新文档和社区讨论中，鲜有关于 XML-RPC 的新内容，而 Web 客户端对 JSON-RPC 的依赖则保证了后者的持续维护和发展。这种资源分配的倾斜表明，XML-RPC 正在演变为一个仅为遗留系统服务的兼容性协议。对于新项目而言，选择 XML-RPC 无疑是选择了一条未来可能缺乏维护和功能更新的技术路径，存在一定的战略风险。

第三节：正面比较分析

为了帮助开发者做出最终决策，本节将从多个维度对 XML-RPC 和 JSON-RPC 进行直接的、并列的比较。

关键差异对比表

下表总结了两种协议在 Odoo 18 环境下的核心区别，并解释了这些差异为何至关重要。

特性	XML-RPC	JSON-RPC	洞察 / 为何重要
数据格式	XML (可扩展标记语言)	JSON (JavaScript 对象表示法)	JSON 更轻量，且能更自然地映射到现代编程语言的数据结构。
载荷冗余度	高 (因起始/结束标签导致)	低 (简洁的键值对)	低冗余度意味着更小的数据包、更快的网络传输和更低的带宽成本。
解析性能	较慢 (需要完整的 XML 解析器)	更快 (通常有原生或高度优化的解析器)	更快的解析速度能降低服务器和客户端的延迟，对高吞吐量应用至关重要。
端点复杂性	两个端点 (`/common` 用于认证, `/object` 用于数据)	单一端点 (`/jsonrpc` 用于所有调用)	单一端点简化了客户端配置，更符合现代 API 的设计模式。
错误结构	`<fault>` 元素，包含 `faultCode` 和 `faultString` (结构化程度低)	标准化的 JSON 对象，包含 `code`, `message`, `data` (结构化)	结构化错误更易于程序化解析，从而实现更稳健和自动化的错误处理。
在 Odoo 中的主要用途	遗留系统集成，历史示例	Odoo Web 客户端的内部 API，现代集成	JSON-RPC 是“活的”API，随每个新功能一同测试。它是新开发项目的权威选择。
原生库 (Python)	`xmlrpc.client` (标准库)	`json` & `urllib.request` (标准库), `requests` (推荐)	两者都得到良好支持，但用于 JSON-RPC 的 `requests` 库提供了更现代、更直观的开发体验。
模式支持	强 (XSD, DTD 用于验证)	弱 (JSON Schema 是一个选项，但集成度较低)	在需要严格数据验证的高度规范化或企业环境中，XML 强大的模式支持是一个优势。

性能与效率深度剖析

上表中的性能差异值得进一步探讨。XML 的“冗余税”是真实存在的。如基准测试所示，XML 格式的数据体积可以比 JSON 大 13% 。这不仅增加了网络传输时间，还消耗了更多带宽。更重要的是解析性能的差异。XML 的文档对象模型 (DOM) 解析在计算上比解析 JSON 更为昂贵，因为它需要构建一个完整的树状结构。

虽然有非 Odoo 场景的基准测试显示，在某些特定查询中，XML 的服务器端处理可能稍快，但这对于 Odoo 的 RPC 调用来说是一个误导。在 Odoo 中，无论是通过 XML-RPC 还是 JSON-RPC 调用，最终执行的都是同一个服务器端的 ORM 方法。因此，服务器端的业务逻辑执行时间是完全相同的。性能的瓶颈和差异主要体现在

网络传输和数据解析这两个环节。在这两个方面，JSON-RPC 都具有压倒性的优势，这意味着对于 Odoo 集成而言，JSON-RPC 的端到端响应时间几乎总是更短。

开发者工效学与工具链

从开发者的角度来看，两种协议的体验也大相径庭。虽然 Python 标准库为两者都提供了支持，但 requests 库的流行使得通过 JSON-RPC 进行 HTTP 通信变得异常简单和愉快。

更重要的是，JSON-RPC 的请求-响应周期对于习惯了现代 Web API 的开发者来说更为直观。使用 Postman 或浏览器开发者工具等常用工具进行调试时，查看和构造 JSON 载荷比处理 XML 更为方便。

虽然存在像 odoo-rpc-client 或 odoorpc 这样的高级库，它们能够抽象掉底层协议的差异，为开发者提供统一的接口。这些库非常方便，可以显著提高开发效率。然而，当遇到复杂的调试场景或需要利用协议的特定功能时，对底层 XML-RPC 或 JSON-RPC 工作原理的理解仍然是不可或缺的。在这种情况下，JSON-RPC 的简洁性和标准化结构使其更易于理解和排错。

第四节：战略性选择：应用场景与建议

选择 API 协议不仅是技术问题，更是与项目目标、团队技能和长期维护策略相关的战略决策。

XML-RPC 的理想应用场景

尽管 JSON-RPC 是未来的方向，但在以下特定场景中，选择 XML-RPC 仍然是合理甚至必要的：

对接遗留企业系统：当需要将 Odoo 与那些拥有成熟、内置 XML-RPC 或 SOAP 库，但缺乏强大 JSON 工具链的旧式企业系统 (如某些 Java 或.NET 应用) 集成时，使用 XML-RPC 可以降低对方的开发成本。
维护现有代码库：如果一个项目已经在一个定制的 XML-RPC 集成层上投入了大量资源，那么进行全面的重写可能不具备成本效益。在这种情况下，继续使用 XML-RPC 进行维护和增量开发是务实的选择。
需要严格模式验证的环境：在某些行业（如金融、政府），数据交换可能要求使用 XML 模式 (XSD) 进行严格的格式和内容验证。如果这是一个硬性要求，并且开发团队在 XML 工具链 (如 XPath, XSLT) 方面拥有深厚专业知识，那么 XML-RPC 的强模式支持将成为一个决定性优势。

JSON-RPC 的理想应用场景

对于绝大多数现代集成需求，JSON-RPC 都是更优的选择：

所有新开发项目：应将 JSON-RPC 作为任何新的 Odoo 18 集成项目的默认和首选协议。
Web 和移动应用后端：当 Odoo 作为 Web 前端 (如 React, Vue, Angular) 或移动应用的后端时，性能和低带宽消耗是首要考虑因素，JSON-RPC 在这方面表现卓越。
微服务架构：在将 Odoo 作为大型微服务生态系统中的一个服务时，JSON 是服务间通信事实上的“通用语言”，使用 JSON-RPC 能更好地融入整个架构。
自动化 Web 客户端操作：对于任何需要精确复制或自动化用户在 Odoo Web 界面中执行的工作流的脚本或应用，使用 JSON-RPC 是最可靠的方法，因为它直接调用了与前端相同的接口。

架构师的最终裁决

综合以上所有分析，对于 Odoo 18 平台的集成开发，最终的架构建议是明确且毫不含糊的：

对于所有新的开发项目，JSON-RPC 都应被视为默认且被强烈推荐的选择。

这一裁决基于以下核心论据的支撑：

性能更优：载荷更小，解析更快，端到端延迟更低。
面向未来：作为 Odoo 官方 Web 客户端使用的核心 API，其功能完整性和未来兼容性得到了最高保障。
开发体验更佳：更符合现代开发者的技术栈和思维模式，工具链支持更友好。
错误处理更稳健：结构化的错误信息便于程序化处理，提高了集成的可靠性。

在此框架下，XML-RPC 应被定位为一个“遗留系统兼容层”。它的使用应该是一个经过深思熟虑的、由特定外部约束驱动的决策，而非默认的技术路径。

结论：做出面向未来的 API 选择

在 Odoo 18 的集成生态中，XML-RPC 和 JSON-RPC 这两种原生协议共同存在，为开发者提供了不同的选择。本文的深度分析表明，XML-RPC 作为一个成熟、稳定的协议，在对接遗留系统和需要严格模式验证的特定场景中仍有其用武之地。然而，其固有的冗余度、较低的性能以及在 Odoo 生态中逐渐边缘化的趋势，使其不再适合作为新项目的首选。

与之相对，JSON-RPC 凭借其轻量、高效、现代化的特性，以及作为 Odoo Web 客户端核心通信机制的特殊地位，已经成为事实上的标准。它不仅在性能上超越了 XML-RPC，更在开发体验和未来兼容性上提供了无与伦比的优势。

因此，开发者在 Odoo 18 上启动新项目时所面临的选择，已不仅仅是一个技术偏好的问题，而是一个影响项目性能、可维护性以及与 Odoo 平台未来发展方向是否一致的战略决策。通过选择 JSON-RPC，开发者不仅是选择了一种数据格式，更是选择与 Odoo 的核心架构对齐，从而为他们的集成方案构建一个更稳定、更高效且真正面向未来的坚实基础。