APIv1: Start working on new REST API. Refactor logic in domains.

[fmartingr]

Meta: #640

Added a proof of concept (extending the idea from #467) with a new API server built on gin.

• Added a separate server command to launch the new HTTP server
• Database interface remains the same, though it should change a little bit, but it works for the PoC.
• Added logic Domains which will encapsulate logic related to Shiori domains, to avoid having duplicated code between the client, the api and the extension API (which will merge)
• Added the Auth Domain, which now checks for an user account based on the credentials (login check) and creates an auth token for an specific account to use as authentication in the API.
• Adds a Makefile with a bunch of QoL commands for contributing, along with some contributing documentation.

Status

UI Routes

Category	Method	Endpoint	Ready	Tested
System	GET	/system/liveness	✅	✅
Bookmarks	GET	/bookmarks/:id/content
Bookmarks	GET	/bookmarks/:id/archive
Bookmarks	GET	/bookmarks/:id/thumb
UI	GET	/*files*	✅

API routes

Category	Method	Endpoint	Ready	Swagger	Tested
Tags	GET	/api/v1/tags	✅	✅	✅
Tags	POST	/api/v1/tags	✅	✅
Tags	PUT/PATCH	/api/v1/tags/:id
Tags	DELETE	/api/v1/tags/:id
Accounts	GET	/api/v1/accounts
Accounts	POST	/api/v1/accounts
Accounts	PUT/PATCH	/api/v1/accounts/:id
Accounts	DELETE	/api/v1/accounts/:id
Accounts	GET	/api/v1/account/me	✅	✅	✅
Accounts	POST	/api/v1/account/login	✅	✅	✅
Accounts	POST	/api/v1/account/refresh	✅	✅	✅
Bookmarks	GET	/api/v1/bookmarks
Bookmarks	POST	/api/v1/bookmarks
Bookmarks	PUT/PATCH	/api/v1/bookmarks/:id
Bookmarks	PUT	/api/v1/bookmarks/:id/cache

Database

Category	SQLite	MySQL	PSQL
CreateTags	✅	✅	✅

Discussion here: #462

Fixes: #571 #184 #463

[hulb]

how about use viper to do these config things?

[fmartingr]

Right now we have a mix of environment variables and CLI flags. I tend to use environment variables because I only use the server version, but we need to figure out what's the best solution for both worlds. Ideally the CLI would read configuration from some file as well. I will take a look at Viper, it seems to provide everything on one package :)

[hulb]

I think it's a little veiled to declare route here. I prefer the original way, put routes together and use difference handlers

[fmartingr]

The problem with using a single package for everything is that after a while you either have huge files containing all kinds of related logic for the API (handlers, payloads, responses, middlewares, codecs, ...). I followed a similar approach here as with the "domains", each endpoint is contained in a "domain", in this case this is the "auth" domain, so all routes for the auth domain are defined here, and all domains are defined in api.go. (auth, bookmarks, tags, ...). As with everything, suggestions welcome!

[hulb]

I get you.I think it's just a matter of taste. I don't think I'm much experienced in dev in go. I can learn from this :)

[fmartingr]

I think we could have the best of both worlds, defining the API in a file and having the handlers and everything related in separate packages. Will try to integrate those changes over the weekend for you to take a look. Even if you think you're not experienced, an extra pair of eyes is always welcome.