[Meta] Improvements to the API

Question

[Meta] Improvements to the API

bkcsoft opened this issue 8 years ago · 22 comments

Meta-issue for everything API related. Please don't close until API is done, and don't set a milestone either since it's long-running

Original Gogs-issue

Related Issues:

~~CI/CD Status ( Gogs Issue )~~
~~PR (#248)~~
~~OAuth-support for API~~
- ~~Related Issue: #27~~
~~Stars (WIP)~~
~~Inconsistencies~~
- ~~Issue Comments~~
- ~~Issue Labels~~
- ~~PR JSON Object~~
~~Releases New PR~~
~~User/Org Repo Listing~~

Not APIs but related:

RSS Support ( Gogs Issue )
- Required for Activity Feed API
- Version Notification
Plugin Infrastructure
- Should really go in go-gitea/proposals, drafts are already done.
~~React UI~~
- As I mentioned in that Issue, a complete API would allow others to implement their own UIs if necessary
- ~~Also ties in with #35~~

Will add more to this list as they keep coming.

~~This also requires us to fork gogits/go-gogs-client~~ done 😄

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

lunny commented 8 years ago

+1

👎2

lunny commented 8 years ago

OK

Answer 1 · 2016-11-04T04:50:38.000Z

@tboerger Should this be a "Project" instead maybe?

Answer 2 · 2016-11-04T08:29:50.000Z

One point I already mentioned on the gitter channel yesterday, IMHO there is a need for automatic documentation (from code / comments in the code) of the api. I think this should be added to this list, there is an initial issue in go-gogs-client mentioning one of the current issues with the docs: gogs/go-gogs-client#46

It seems swagger is the most popular solution currently and it seems there is a go implementation

Answer 3 · 2016-11-04T08:43:04.000Z

Yep 👍 for swagger

Answer 4 · 2016-11-04T08:52:20.000Z

Maybe a project should be better to keep an overview of missing parts.

Answer 5 · 2016-11-04T10:14:13.000Z

@tboerger AFAIK it's hard to make generic comments (like @hhenkel just did) on a Project?

Answer 6 · 2016-11-04T13:19:39.000Z

We should create issues for all of that.

Answer 7 · 2016-11-09T04:56:00.000Z

I think this should be the emphasis of v1.1. So we have to list all the APIs should github have. And implements it one by one. For example, we can implement https://developer.github.com/v3/repos/statuses first?

Answer 8 · 2016-11-10T13:38:00.000Z

@lunny I have a few PRs coming, but I'll continue with the rest of the API after that starting with Status API :)

Answer 9 · 2016-12-20T15:34:04.000Z

Please add API for POST /api/v1/repos/:owner/:repo/forks. It's very important feature.

Answer 10 · 2016-12-25T09:16:44.000Z

@pyhedgehog Please make an issue for that, since this is just a Meta-issue for tracking API-changes 🙂

Answer 11 · 2016-12-25T16:34:45.000Z

@bkcsoft, #477 + #494.

Answer 12 · 2017-01-29T22:03:10.000Z

@lunny

and don't set a milestone either since it's long-running

Answer 13 · 2017-02-10T13:27:24.000Z

But since it will be done within the 1.x.x livetime I will set it to 1.x.x milestone

Answer 14 · 2017-02-12T08:42:21.000Z

(GitHub needs more reactions! )

Answer 15 · 2017-12-31T01:27:29.000Z

@bkcsoft I updated the issue, seems almost done. 😄

Answer 16 · 2018-05-05T21:50:33.000Z

Mentioning #3076 (add github compatible v3 routes) here for searchability.

Answer 17 · 2019-03-24T09:09:52.000Z

Will the GraphQL-API be supported?

Answer 18 · 2019-03-25T07:05:10.000Z

There is an issue to report that.

Answer 19 · 2020-11-24T21:57:03.000Z

beside api unrelated & feed API, everything is here.

should we close this now?

Answer 20 · 2020-11-24T22:00:32.000Z

ok since https://github.com/go-gitea/gitea/issues?q=is%3Aissue+is%3Aopen+label%3Akind%2Fapi+label%3Akind%2Fproposal

summary it well, I'll close this now - if there is a need for a summary issue on API stuff, just ask and I'll open a new one :)