HTTP status codes from the JSON-RPC api

[Gavin Andresen]

I just submitted a patch to Satoshi to make bitcoin follow the JSON RPC over HTTP spec, and to use the standardized error codes from the JSON-RPC 1.1/2.0 specs.

If you talk directly to bitcoin via JSON-RPC calls, you might need to change your code to recognize the new HTTP status codes and the new format for the 'error' member of the JSON response.  For example:

BEFORE, send {"id":"123", "method": "nosuchmethod", "params": [] } , get response:

Code:

HTTP/1.1 500 Internal Server Error
...

{"result":null,"error":"Method not found.","id":"123"}

AFTER:

Code:

HTTP/1.1 404 
...

{"result":null,"error":{"code":-32601,"message":"Method not found"},"id":"123"}

I also removed the broken 'Batch' support, to simplify the code.  I had JSON-RPC-2.0 batch support working properly, but backed those changes out because JSON-RPC 2.0 is way too cutting-edge for bitcoin to support right now (none of the JSON-RPC glue libraries support it yet, and the spec is still changing a bit).

[1715181860]

1715181860

[1715181860]

1715181860

[1715181860]

1715181860

[1715181860]

1715181860

[Gavin Andresen]

Speak now about this change or forever hold your peace...  Satoshi will be including this functionality in the next version of Bitcoin (0.3.12).

If you use the JSON-RPC api, you should check your error-condition-handling code; again, the changes are that the error member will be an Object (with 'code' and 'message' fields) instead of a String, and the HTTP status code may be 404 instead of 500 for method-not-found.

[satoshi]

This is in SVN rev 147.

This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct.  The code/message members have become standard in later json-rpc specs.

If you have code that checks the error and expects a string, you'll need to change it.  When there is an error, the error member is now an object not a string.

Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code.  Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The "backupwallet <destination>" command that was discussed in another thread.  It locks the wallet and copies it, so you can be sure you get a correct copy.

[nelisky]

This is in SVN rev 147.

This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct.  The code/message members have become standard in later json-rpc specs.

If you have code that checks the error and expects a string, you'll need to change it.  When there is an error, the error member is now an object not a string.

Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code.  Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The "backupwallet <destination>" command that was discussed in another thread.  It locks the wallet and copies it, so you can be sure you get a correct copy.

Woot, double thumbs up on this. Great work, satoshi!