Open ixje opened 6 days ago
This behavior goes back to 19a430b262dc418a17a781200c0ba7ca5a2148b1. Not that we've never seen it, it was always suspicious, but it worked well and I'm still not sure what can be affected if we're to change it. Also, JSON-RPC itself doesn't specify how to use it over HTTP.
Let's review other codes as well while we're here and try to pick the best practices. This spec is outdated, but still has some ideas for HTTP codes: https://www.jsonrpc.org/historical/json-rpc-over-http.html, also https://stackoverflow.com/questions/76860816/json-rpc-v2-api-http-layer-what-are-the-appropriate-http-layer-status-codes-fo.
from the comment on the last post
The gist of both of these is that non-200 codes are for indicating a problem with the HTTP transport, and not for errors that are related to the semantics of the method call.
That seems to be inline with what C# is doing. Most HTTP request libraries also suggest some flow of
The way neo-go works now means I need to remove the 2nd step (which sometimes is even done implicitly by libraries) or I can't get to the point that processes the actual error from the JSON-RPC error.
Current Behaviour
Expected Behavior
status code 200 like C#
Similarly an invalid
invokescript
returns 200 on C# and 400 with neo-go.Possible Solution
change status code to 200
From https://www.rfc-editor.org/rfc/rfc4918#section-11.2
I assume the reason came from the bold part, but is that really fair? It actually is able to process the instructions in the request, its just that it couldn't find what was asked for. This feels like throwing a 422 just because you called
getnep17balances
expecting there to be some but there were noneYour Environment
0.106.3