Documenting bukuserver API

[LeXofLeviafan]

The startup bukuserver code sets up a handful of /api routes; as far as I can tell, only /api/tags is actually used within the app. Are the rest of these endpoints legacy code, or are they meant for external usage? I reckon the API should either be cleaned up or documented (it doesn't even seem to be mentioned in readme at the moment).

[rachmadaniHaryono]

They are meant for external usage

They are actually the main reason for bukuserver development

Maybe because there's no doc there's also no one want to develop program with it

[LeXofLeviafan]

Maybe because there's no doc there's also no one want to develop program with it

That does sound like a defining factor, yes 😄

Even in the main buku readme, bukuserver is only ever referred to as a GUI – there's no mention of a web-API anywhere.

[rachmadaniHaryono]

So basically

• edit the doc to mention bukuserver web api
• have better doc on api ,open api https://www.openapis.org/, maybe add screenshot
• ask if any developer interested on api in next release

[LeXofLeviafan]

…Might also be a good idea to move the API MethodViews into a separate file.

[rachmadaniHaryono]

at first i want to put that on lower priority

but organized api code will make life easier for docs writer and developer, so maybe yes

[2ynn]

Hi, I'd be interested in working on this. Would you be open to set up SwaggerUI?
e.g.
https://github.com/sveint/flask-swagger-ui
https://github.com/flasgger/flasgger
https://github.com/overflowdigital/Flask-OpenAPI

[LeXofLeviafan]

That sounds like a good idea to me. Though, a static (if brief) description in bukuserver readme would still be necessary.