API UX: internal IDs shouldn't leak #6531

New Issue

GiteaMirror · 2025-11-02T06:58:39-06:00

GiteaMirror commented

2025-11-02 06:58:39 -06:00

Originally created by @noerw on GitHub (Dec 16, 2020).

Working with the gitea API in tea, I noticed some shortcomings:

Labels are referenced by ID when attaching to issues / pulls. Users don't know this ID, and don't need to know; the label name is the user facing ID. Also, there is no way to look up a label ID by label name.
Similar problem exists with issue milestones: To assign a milestone, I need to know the internal ID, which is not how users identify milestones.

I propose to resolve these name <-> ID mappings internally and not leak this internal data model detail. Changes would be breaking, but IMO they're worth it.
This increases both usability as well as performance, as no more extra roundtrip to resolve IDs would be needed.

Originally created by @noerw on GitHub (Dec 16, 2020). Working with the gitea API in `tea`, I noticed some shortcomings: - Labels are referenced by ID when attaching to issues / pulls. Users don't know this ID, and don't need to know; the label name is the user facing ID. Also, there is no way to look up a label ID by label name. - Similar problem exists with issue milestones: To assign a milestone, I need to know the internal ID, which is not how users identify milestones. I propose to resolve these name <-> ID mappings internally and not leak this internal data model detail. Changes would be breaking, but IMO they're worth it. This increases both usability as well as performance, as no more extra roundtrip to resolve IDs would be needed.

GiteaMirror added the type/proposal topic/ui-interaction modifies/api labels 2025-11-02 06:58:39 -06:00

GiteaMirror commented

2025-11-02 06:58:40 -06:00

@lunny commented on GitHub (Dec 16, 2020):

milestone should have an index like Issues/PRs

@lunny commented on GitHub (Dec 16, 2020): milestone should have an index like Issues/PRs

GiteaMirror commented

2025-11-02 06:58:40 -06:00

@lafriks commented on GitHub (Dec 16, 2020):

Problem is that currently labels are not required to have unique name so this will not work if they have same name. Also how would you know if that is organization or repository label as they also can have same name.

@lafriks commented on GitHub (Dec 16, 2020): Problem is that currently labels are not required to have unique name so this will not work if they have same name. Also how would you know if that is organization or repository label as they also can have same name.

GiteaMirror commented

2025-11-02 06:58:40 -06:00

@CirnoT commented on GitHub (Dec 16, 2020):

milestone should have an index like Issues/PRs

Impossible, because organization labels are shared.

@CirnoT commented on GitHub (Dec 16, 2020): > milestone should have an index like Issues/PRs Impossible, because organization labels are shared.

GiteaMirror commented

2025-11-02 06:58:41 -06:00

@CirnoT commented on GitHub (Dec 16, 2020):

Problem is that currently labels are not required to have unique name so this will not work if they have same name

That should definitely be enforced.

Also how would you know if that is organization or repository label as they also can have same name.

Sets should be merged internally, in case of duplicates repo label takes precedence over organization label

@CirnoT commented on GitHub (Dec 16, 2020): >Problem is that currently labels are not required to have unique name so this will not work if they have same name That should definitely be enforced. > Also how would you know if that is organization or repository label as they also can have same name. Sets should be merged internally, in case of duplicates repo label takes precedence over organization label

GiteaMirror commented

2025-11-02 06:58:41 -06:00

@a1012112796 commented on GitHub (May 14, 2021):

Labels are referenced by ID when attaching to issues / pulls. Users don't know this ID, and don't need to know; the label name is the user facing ID. Also, there is no way to look up a label ID by label name.

In curent design, user should get it by GET /repos/{owner}/{repo}/labels which will include label id response.

@a1012112796 commented on GitHub (May 14, 2021): > Labels are referenced by ID when attaching to issues / pulls. Users don't know this ID, and don't need to know; the label name is the user facing ID. Also, there is no way to look up a label ID by label name. In curent design, user should get it by ``GET`` ``/repos/{owner}/{repo}/labels`` which will include label id response.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6531