Cannot Validate against schema = false.
daeros opened this issue · comments
from jsonrpcclient import request
import os
from json import JSONDecoder
import jsonschema
also go into the top right corner, hit your user name, hit edit profile, then go to API and extract your API key and
api_key = "censored"
with open("List_of_snatched.txt", "w") as List_of_snatched:
try:
response = request("https://api.broadcasthe.net/", "getUserSnatchlist", key=api_key, results = 4000, validate_against_schema = False)
List_of_snatched.write(response.data.result)
except jsonschema.exceptions.ValidationError as e:
print(msg)
data = JSONDecoder().decode(msg)
List_of_snatched.write(data.result)
the problem here is that BTN doesn't use the proper schema, for instance it's json response it returns content enclosed in single quotes and if you switch them to double quotes there's 's in the names and it errors as well...
Looking through the source code, that "parse.get_response" method assumes that the response has passed the schema validation even though it's possible to turn that off.
this should be fixed, it should not assume. and honestly the person who says you should remove this is wrong, there are JSON sites out there that are NOT validly schemed and we should be able to work with them.
I'm having a devil of time trying to figure out how to use another library as a result of this bug...
If I understand correctly, you can disable schema validation, but then the library errors in the get_response function. Is that right?
I've observed the same behaviour when interacting with an endpoint that returns more entries on the JSON-RPC response object (other than jsonrpc, id, result/error). Schema validation doesn't catch this deviation from the standard (if it is one) and get_response (JSONRPCResponse's init, actually) throws due to unexpected keyword argument.
This library is an implementation of the JSON-RPC standard. If we start trying to make it work with garbage responses, I feel this will be a losing battle.
@pgold you might be interested in my comment here #102 (comment)
This library is an implementation of the JSON-RPC standard. If we start trying to make it work with garbage responses, I feel this will be a losing battle.
I agree on sticking to the JSON-RPC standard, and it's mildly infuriating to myself that the endpoint I'm interacting with returns this information out of band and encroaching on the JSON-RPC "layer".
Upon re-reading the relevant section of the standard (https://www.jsonrpc.org/specification#response_object), my interpretation is that returning additional entries would be permissible.
@pgold you might be interested in my comment here #102 (comment)
Thanks! I've tried it (with websockets), but I think at this point the library wouldn't be doing much.
The result section lets you put as much as you like in there, i'm not sure why you'd need to put anything extra outside of it.
@pgold which part do you interpret as saying extra entries being permissible?
"The Response is expressed as a single JSON Object, with the following members: jsonrpc [...], result [...], error [...], id [...]."
I interpret it as: the response must have these members, but not only these members.
The
resultsection lets you put as much as you like in there, i'm not sure why you'd need to put anything extra outside of it.
Agreed. The only reason I can think of is that the API authors must have wanted to report some request meta-data while guaranteeing that the result is the same for equivalent requests. For example:
request: { "jsonrpc": "2.0" "method": "get_product" "params": {"product_id": 123} "id": 1 };
response: { "jsonrpc": "2.0" "result": {"product_id": 123, [...]} "id": 1, "processing_time": 25, }.