Zend_Json_Server 与 JSON-RPC 规范

Posted

技术标签:

【中文标题】Zend_Json_Server 与 JSON-RPC 规范【英文标题】:Zend_Json_Server vs JSON-RPC spec 【发布时间】:2012-01-11 17:02:32 【问题描述】:

JSON-RPC 2.0 协议的 ZF 实现只允许错误码:

const ERROR_PARSE           = -32768;
const ERROR_INVALID_REQUEST = -32600;
const ERROR_INVALID_METHOD  = -32601;
const ERROR_INVALID_PARAMS  = -32602;
const ERROR_INTERNAL        = -32603;
const ERROR_OTHER           = -32000;

加,范围(-32099,-32000)

这些在 JSON-RPC 规范中定义为预定义和/或保留。至少这是规范之外的内容:

从 -32768 到 -32000 的错误代码保留用于预定义的错误。此范围内但未在下面明确定义的任何代码都保留以供将来使用。错误代码与以下 url 中为 XML-RPC 建议的错误代码几乎相同:http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

代码消息含义 -32700 解析错误 服务器接收到无效的 JSON。 解析 JSON 文本时服务器发生错误。 -32600 无效请求 发送的 JSON 不是有效的请求对象。 -32601 Method not found 该方法不存在/不可用。 -32602 Invalid params 方法参数无效。 -32603 内部错误 内部 JSON-RPC 错误。 -32000 到 -32099 服务器错误 为实现定义的服务器错误保留。

剩余空间可用于应用程序定义的错误。

它没有说你不能,例如使用 -100 或 100。我错过了什么吗?

在某处我认为 ZF 将“服务器错误”和“应用程序错误”混淆为同一件事,而在阅读上面的 sourcefourge 链接时,协议的作者显然有不同的想法,允许应用程序开发人员空间很大:

此外,-32099 .. -32000(含)范围保留用于实现定义的服务器错误。没有完全映射到此规范定义的特定错误的服务器错误应分配给此范围内的数字。这为应用程序定义的错误留下了剩余空间。

【问题讨论】:

有人吗?我什至创建了一张票,但我得到的只是 O'Phinney 没有解决问题的评论:framework.zend.com/issues/browse/… 【参考方案1】:

我在一些项目中使用了 ZF 的 JSON-RPC 组件。它工作得很好——但我几乎不会认为它是 JSON-RPC 规范的典范。据我所知,实际上只有几个客户端针对 Zend_Json_Server 测试了他们的实现,因此它几乎没有被广泛采用。有一次,我实际上必须修补 Zend_Json_Server 以使其与一个客户端一起工作,因为它没有正确遵循规范(此后已修复)。

所以基本上我说的是“好点,你可能是对的”。如果它足够痒,只需fork zf2 并提交一个更好地实施规范的拉取请求 - 当您查看差异时更容易获得正面/负面反馈。

如果他们接受,请提交补丁以供 zf1 合并到下游。

【讨论】:

我们只是覆盖了 Zend_Json_Server::fault() 和 Zend_Json_Server 解决了这个问题,至少对我们来说是这样。我创建了一张票来报告问题,如果没有人可以费心好好看看这个问题,那就这样吧。我不会浪费我更多的时间来附加一个永远不会被查看的补丁。 FWIW,对 zf2 的拉取请求总是被查看。

以上是关于Zend_Json_Server 与 JSON-RPC 规范的主要内容,如果未能解决你的问题,请参考以下文章

__call 等效于公共方法

在 ZEND 中处理 JSONP 调用

我可以使用 JSON-RPC 将文件发布到网络服务吗?

LDAP 与 MYSQL .. JA-SIG CAS 与 LDAP 与 CAS 与 MySQL

python网络编程基础(线程与进程并行与并发同步与异步)

=与==&与&&| 与 || 的区别