Gitea: [Meta] Improvements to the API

[bkcsoft]

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 :trollface:

Original Gogs-issue

Related Issues:

• ~CI/CD Status ( Gogs Issue )~
• ~PR (https://github.com/go-gitea/gitea/pull/248)~
• ~OAuth-support for API~
  
  
  
  • Related Issue: https://github.com/go-gitea/gitea/issues/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 :smile:

---

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

[bkcsoft]

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

[hhenkel]

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: https://github.com/gogits/go-gogs-client/issues/46

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

[metalmatze]

Yep :+1: for swagger

[tboerger]

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

[bkcsoft]

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

[tboerger]

We should create issues for all of that.

[lunny]

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?

[bkcsoft]

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

[lunny]

+1

[pyhedgehog]

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

[bkcsoft]

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

[pyhedgehog]

@bkcsoft, #477 + #494.

[bkcsoft]

@lunny

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

:trollface:

[lunny]

OK

[tboerger]

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

[bkcsoft]

:trollface: (GitHub needs more reactions! )

[lunny]

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

[stevegt]

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

[Serkan-devel]

Will the GraphQL-API be supported?

[lunny]

There is an issue to report that.