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 メソッドが見つかりません メソッドが存在しない/使用できません。-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 にパッチを適用して、1 つのクライアントで動作するようにする必要がありました。これは、仕様に正しく準拠していなかったためです (その後修正されました)。

だから基本的に私が言っているのは「良い点、あなたはおそらく正しい」ということです。それが十分にかゆい場合は、zf2 を forkし、仕様のより良い実装でプル リクエストを送信してください。差分を見ているときに、肯定的/否定的なフィードバックを得るのがはるかに簡単です。

彼らがそれを受け入れる場合は、ダウンストリームでマージするための zf1 のパッチを提出してください。

于 2012-01-19T17:45:56.543 に答える