-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Methods for alternative org routes #15
Comments
It's complicated. They What I would recommend for the time being is to use the lower-level const { data } = await octokit.request('/repositories/:id', {
id: 123
}) |
This comment has been minimized.
This comment has been minimized.
I wonder what the ideal API would be from your perspective? There is a total of 4 routes that are aliases:
Would you rather have 4 different methods? Or a single method that would accept one of Maybe mixing slug/name URL parameters with |
I would rather have 4 different methods, I think... combining would be a little too complicated I feel. Without an understanding of the backend at GitHub and its API system, I just have to imagine that ID-based routes should be a good thing when names and slugs can change... |
The ID-based APIs are still not part of GItHub's official OpenAPI spec. Once they will, we will get the endpoint methods and the TypeScript intellisense for the routes. Until then, there is not much we can do |
Is this still an issue? |
I think so? I don't think the |
With the move in the latest releases to begin legacy deprecation of a few of the get-by-ID style APIs such as
teams.getLegacy
, I'm wondering what the maintainers think about exposing officially the newer org-based get by ID routes directly?While there is some prior history in this project around the
/repositories/:id
endpoint that was not officially documented (see: #163), the newer routes such asGET /organizations/:org_id/team/:team_id
are mentioned in the official documentation for the APIs such as "Get team by name" at https://developer.github.com/v3/teams/#get-team-by-name.As a GitHub App developer, we're often having to worry about multi-hop resolutions to accommodate renames of teams, repos and other assets, and even orgs, so being able to directly hit ID-based routes by org ID and team ID drastically reduces errors and the need to implement eventual consistency checks that look for renamed slugs, names, etc.
Obviously not a blocker, since we can still directly call the routes from Octokit rest.js without an actual named method; however, it's possible that other app developers adopting this library may use the numeric ID-based routes if the methods were exposed, potentially yielding less errors or end user experience issues.
There may be prior conversations documented elsewhere (there's mention of "consensus around ID names" in https://github.com/octokit/rest.js/issues/886) but I can't find more context.
Thanks for your thoughts. Happy to help expose the methods if there is interest in this; otherwise, this issue, when closed with comments, can help provide historical context for others who have the same question.
The text was updated successfully, but these errors were encountered: