DavisVaughan
commented
6 years ago It kind of depends on how good the API errors are. Normally I do some kind of validity checks on the class of the object, and maybe some other lower level feature. Like limit should be a non-negative integer, which we can check, but we would let the API check to see if it goes >1000 or >100000 since it changes depending on the endpoint. Other things we can do are ensure that limit is an integer (100L) even if the user passes a numeric (100), because it doesn't work with numerics. We can perform that autoconversion for them.
Another thing I was planning on doing is making observation_date (and others like it) only accept Date objects rather than strings. That way, the format is always correct which we can then use format(x, format = "%Y-%m%-%d") on to get it in the right format for the API. It also allows us to have unit tests on the observation_date parameter by checking for a Date class.
Generally, I was planning on having a capture_args(...) function that will accept all parameters and perform checks and modifications on them, and will return a param list that can be passed on to use in the API call. I will explain more in the PR tonight
sboysel
As of now, unit testing is quite haphazard. I'd like to establish a consistent set of tests for each function.
fredr_set_key()- fine as isfredr()fredr()Note that the FRED API will return
404error if the request URL is not found (e.g. bad endpoint passed tofredr())400if the endpoint is value but the request is improperly formed (e.g. bad parameters passed tofredr()or the endpoint functions).Some initial testing suggests the FRED API
400codes return useful error messages for bad values and that improperly named parameters are simply ignored (explicitly defined parameters would solve this anyways).* @DavisVaughan What would you consider best practice for errors in an API package: check that parameter value types are proper before* sending the request or allow the API to return an error?