corpetty
Method Data Return
I have been trying to determine what data ought to be returned with a method call. As of right now most methods return only the "result" from the json request but leave of the "status" and "message" portion. I am wondering if the user of the python api should be getting the whole request back? My reasoning is that there should be an error check implemented somewhere. For example if you make an erroneous request it returns following:
{"status":"0","message":"No transactions found","result":[]}
Should the error check be handled by the python (internally) or by the api user (externally)?
I think I found a nice solution...
I utilized the python equivalent of an anonymous inner class, type, to return an object with the instance variables: status, message, result. Example:
if req.status_code == 200:
# Check for empty response
if req.text:
return type('', (object,), json.loads(req.text))
else:
print("Invalid Request")
exit()
As you can see in the documentation, type will take the dictionary values and turn them into instance variables and thus are accessible as seen below.
This will enable the API user to select which section of the response that they wish to read. It also enables them to check the status of the request placing the burden on the user to handle invalid api responses as does python's built in request client (e.g. if requests.status_code == 200:)
For the time being, the subclass will only need a minor revision as shown below:
| Current | Revised |
|---|---|
req['status'] |
req.status |
req['message'] |
req.message |
req['result'] |
req.result |
However, in the future I would like to return the whole object to the user. That would require heavy revisions of the account class. Although I do believe that these changes would be beneficial.
Can you give me an idea of the potential benefits of returning the whole object, and offloading the handling to the user?
I do like the idea of returning a object instance, which lends to more of an OOP style.
- I think that it would look more elegant
- It would also enable those using a Smart IDE to use auto-complete which is handy
- It would allow the user more flexibility. For instance, when performing iterable tasks they could check
if req.status == '1'which would allow for them to, more conveniently, handle errors in their implementation.
Just a thought!
I think this is a good idea, just because increased generality is better than not. I don't think the userbase of this package is large enough to impact serious projects either.
Thanks for asking!
So basically we change the json dictionary-like response to a more object like to access it using result.attribute rather than result['key'] correct? I'm fine with that.
But you also suggested something about giving more context from the response, like Response.status_code correct? That I also like, but I doesn't seem to be the case when doing type('', (object,), json.loads(req.text)) as you suggested, is it?
Yes. They are somewhat related. Turing it into an object will enable the implementation to access parts of the JSON if need be. But generally, we'll want to return the whole JSON response right?
Yes agree to have the entire JSON response. The question is also the requests.Response object, that's the one that contains HTTP status_code.
hi,when I use the parameter “&to=” to filter the transction ,but the result return is the same ,does not the prrameter work?
