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不是有效的Request对象。 -32601未找到方法该方法不存在/不可用。 -32602无效的参数无效的方法参数。 -32603内部错误内部JSON-RPC错误。 -32000到-32099服务器错误保留用于实现定义的服务器错误。
该空间的剩余部分可用于应用程序定义的错误。
没有任何地方说你不能，例如使用-100或100.我错过了什么？
在某些地方我认为“服务器错误”和“应用程序错误”已被ZF混淆为同样的事情，而在阅读上面的sourcefourge链接时，显然协议的作者有一些不同的想法，允许应用程序开发人员很多空间：
此外，范围-32099 ..-32000（包括）保留用于实现定义的服务器错误。不能完全映射到此规范定义的特定错误的服务器错误应分配给此范围内的数字。这使剩余的空间可用于应用程序定义的错误。
答案 0 :(得分：0)
我将ZF的JSON-RPC组件用于一些项目。它工作得很好 - 但我几乎不认为它是JSON-RPC规范的示例。据我所知，只有几个客户实际上测试了他们对Zend_Json_Server的实现，所以它几乎不是一个广泛采用的实现。有一次，我实际上不得不修补Zend_Json_Server以使其与一个客户端一起工作，因为它没有正确地遵循规范（那是因为已经修复）。
基本上我说的是“好点，你可能是对的。”如果它足够痒，只需fork zf2并提交一个更好实施规范的拉取请求 - 当您查看差异时，更容易获得正面/负面反馈。
如果他们接受，请提交zf1补丁以合并到下游。