listmonk
listmonk copied to clipboard
Public API
Hey — first off. Thanks for publlishing listmonk. It's been pretty nice and easy to work with.
I was wondering if you'd take a PR for a small "public API".
I am basically looking for (something like):
GET /public-api/lists
— which returns all public lists
POST /public-api/subscribe
— which lets me subscribe
Idea is to be able to use these APIs from a fetch/ajax or programmatically from non-web apps (like CLI).
Anyway, I would model the data close to your forms/html views that you currently have. This would be exactly like the current web experience, but maybe a bit more flexible for integration, etc..
Would you be open for that?
Sorry, missed this issue! Yes, /api/public/*
makes sense.
For subscription, it's already possible to do a POST to /subscription/form
and check for a 200 response. Awkward, but works.
No worries. Thanks for considering my idea. 😃
What do you think about using an accept header to change the current routes? If the request contains Accept: application/json
, it's an API. Then it's all one?
That makes sense, but since we have the /api
convention for all API endpoints, it'd be best to keep it consistent.
I think I added a handler in the right places, but I can't test as I can't get the frontend
part to build. It demands an update of the "browserlists" npm package, but I can't shuffle it in.
I then tried to add a go test, but since everything is in main
(which includes an init
), mocking anything is a nightmare.
I think almost everything in cmd/
should probably move into a pkg/listmonk
. It's a drastic change though, and I don't know what else you are working on. Are you in favour of it?
I published a WIP here: https://github.com/knadh/listmonk/pull/910
Essentially, the yarn error is a problem and then the go-testing is what I mentioned above. I'll tinker a bit more. But let me know if you have thoughts.
This is now merged in https://github.com/knadh/listmonk/commit/8ace25849e559c8bad7a10635008685a2a7d636c