3

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（含）保留用于实现定义的服务器错误。没有完全映射到此规范定义的特定错误的服务器错误应分配给此范围内的数字。这为应用程序定义的错误留下了剩余空间。

4

1 回答 1

0

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

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

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

于 2012-01-19T17:45:56.543 回答