Categories Endpoints - API v1#28
Conversation
|
hey @KyleSJohnston thank you for the contribution! Very welcome to contribute improvements and increase API coverage, which was on my original roadmap but I never got to it. Will review this PR as soon as possible, and I can also review subsequent PRs on the roadmap that you laid out |
|
I probably won't be able to get to this until Monday, but I'll start to stack some PRs with suggestions. Over this week, I've collected my ideas for wrapping the API in a repo: https://github.com/KyleSJohnston/FredAPI.jl. It might do a better job of reflecting my concept of a 0.7.0 release, though it lacks the code necessary to integrate the existing |
|
Hi @micahjsmith! I wanted to make sure you saw #29 and weren't held up on any permissions issues that I need to resolve. That's the base of a set of stacked PRs, which would do what I had outlined here but replace this PR entirely. Let me know if there's anything I need to do on my end. Thanks! |
|
Hi @micahjsmith...just checking back in on this. I just want to verify that I wasn't blocking anything. |
Hi @micahjsmith !
I was interested in working with some of the FRED data in Julia, and I discovered FredData.jl. I'm relatively new to FRED, and discoverability is especially important to me. I want to be able to search for data and retrieve related series/tags/sources/etc. Instead of writing a new package, I decided I would offer my contributions to FredData.jl directly in light of #13 —even though the last commit in the repo was several years ago.
This PR includes functions for each of the Categories endpoints in the documentation:
fred/categoryfred/category/childrenfred/category/relatedfred/category/seriesfred/category/tagsfred/category/related_tagsTo avoid breaking any existing logic, these functions were added to the
FredData.Categoriessub-module. A newtestsetwas added to the bottom of test_with_key.jl to make sure these behave as expected.My implementation defaults on a global API key instead of the
Fredstruct. I did this for several reasons: the API key is required, users are unlikely to need multiple API keys in the same Julia process, and the existing interface can call the new code with the keyword argument (i.e.:category(...; api_key=fred.key)) if desired.I appreciate that reviewing code is a non-trivial effort, but if you're happy with the general direction, I would be willing to keep working toward more comprehensive API coverage. The target would be:
TODOcomments and in alignment withvalidate_args!TagsResponseshould be placed wherefred/category/tags,fred/series/tags, andfred/tagscan reference it.)If you have no interest or would rather leave the package in the current state, just let me know so I can write the code elsewhere.
Thanks,
Kyle