Zend_Json_Server VS JSON-RPC規範

的ZF實施JSON-RPC 2.0協議的只允許錯誤代碼：Zend_Json_Server VS JSON-RPC規範

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未找到方法該方法不存在/不可用。 -32602無效的參數無效的方法參數。 -32603內部錯誤內部JSON-RPC錯誤。 -32000到-32099服務器錯誤保留用於實現定義的服務器錯誤。

剩餘空間可用於應用程序定義的錯誤。

它沒有說你不能，例如使用-100或100。我是否錯過了什麼？

某處我認爲ZF將「服務器錯誤」和「應用程序錯誤」混淆爲同一件事，而在閱讀上面的sourcefourge鏈接時，顯然協議的作者有着不同的想法，允許應用程序開發人員很多空間：

此外，範圍-32099 .. -32000（含）是爲實現定義的服務器錯誤保留的。服務器錯誤不能幹淨地映射到由此規範定義的特定錯誤應該被分配給這個範圍內的一個數字。這將剩下的空間用於應用程序定義的錯誤。

來源

2012-01-11 user1050499

有人嗎？我甚至創造了一張票，但我得到的只是O'Phinney的一則評論，並沒有解決這個問題：http://framework.zend.com/issues/browse/ZF-11991？focusedCommentId = 49518＃comment-49518 – user1050499 2012-01-17 10:05:43

我使用幾個項目的ZF的JSON-RPC組件。它工作得很好 - 但我幾乎不認爲它是JSON-RPC規範的範例。據我所知，只有幾個客戶端實際上針對Zend_Json_Server測試它們的實現，所以它不是一個廣泛採用的實現。有一次，我實際上必須修補Zend_Json_Server才能使它與一個客戶端一起工作，因爲它沒有正確地遵循規範（從那以後就被修復了）。

所以基本上我說的是「好點，你可能是對的。」如果足夠癢，只需fork zf2，並提交更好的規範實施的拉取請求 - 當您查看差異時，更容易獲得正面/負面反饋。

如果他們接受它，請提交zf1的補丁以在下游進行合併。

來源

2012-01-19 17:45:56

我們只是覆蓋瞭解決問題的Zend_Json_Server :: fault（）和Zend_Json_Server，至少對我們來說。我創建了一張票來報告問題，如果沒有人可以費心去體面看待問題，那麼就這樣吧。我不會浪費更多時間，只需附上永遠不會看到的補丁。 – user1050499 2012-01-30 14:50:49

FWIW，對zf2的請求總是會被查看。 – 2012-01-30 16:47:06

Zend_Json_Server VS JSON-RPC規範

回答

相關問題