Skip to content

Categories Endpoints - API v1#28

Open
KyleSJohnston wants to merge 4 commits intomicahjsmith:masterfrom
KyleSJohnston:feature/categories
Open

Categories Endpoints - API v1#28
KyleSJohnston wants to merge 4 commits intomicahjsmith:masterfrom
KyleSJohnston:feature/categories

Conversation

@KyleSJohnston
Copy link
Copy Markdown

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/category
  • fred/category/children
  • fred/category/related
  • fred/category/series
  • fred/category/tags
  • fred/category/related_tags

To avoid breaking any existing logic, these functions were added to the FredData.Categories sub-module. A new testset was 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 Fred struct. 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:

  • Version 0.7.0 (so existing users can pin to 0.6.0)
  • Support for Julia 1.10 (LTS) and 1.12
  • Functions for Releases, Series, Sources, and Tags endpoints
  • Improved argument validation as suggested by my TODO comments and in alignment with validate_args!
  • Documentation and CI for the new code
  • Some refactoring of the code in this PR for reuse (i.e.: TagsResponse should be placed where fred/category/tags, fred/series/tags, and fred/tags can 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

@micahjsmith
Copy link
Copy Markdown
Owner

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

@KyleSJohnston
Copy link
Copy Markdown
Author

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 FredSeries and get_data functions. I'm happy to collaborate and fold the good ideas into this package.

@KyleSJohnston
Copy link
Copy Markdown
Author

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!

@KyleSJohnston
Copy link
Copy Markdown
Author

Hi @micahjsmith...just checking back in on this. I just want to verify that I wasn't blocking anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants