Improvement: REST API

[freefd]

Implement the REST API for configuration and LCM.

1. GET of runtime configuration:
   1. JSON format
   2. YAML format
2. GET of pprof data:
   1. cmdline
   2. profile
   3. heap
   4. goroutine
   5. block
   6. trace
3. PUT/PATCH of runtime configuration
   1. JSON format
   2. YAML format
4. Control of daemon:
   1. Store runtime configuration to a persistent storage
   2. Reload
   3. Shut off

Or use it to interact with 3rd-party systems, e.g.:
An external system automatically creates an additional Zone in the Frigate configuration for a certain camera, it should also automatically propagate this new Zone to frigate-notify configuration.

But I still think the API design requires implementing muti-account support from request Multiple consumers for a single "Alerts" notifier first.

Based on this API, a UI can be implement later for Very simple configuration Editor request.

[0x2142]

Thanks for putting this together. I've had some ideas for implementing a REST API for a while, but wasn't sure if it made sense for this project. But certainly if we wanted to look at any sort of web UI for config, this would be a prerequisite.

From the perspective of updating / modifying config - this might be a longer-term item, since I would probably need to re-work how I'm doing config checks / validation now & think about how that plays into updating config via API. But perhaps in the meantime, I might be able to start working on some of the easier bits like reading the config, reloading, stats, etc.

[maylorian]

One thing that I wanted to hack in but maybe makes sense to expose in an API is a way to pause notifications. What I want to achieve is, I want to receive notifications only when my home alarm is on. If it's off, it means I'm at home and I probably wonder around the yard, in which case, I don't really need the notifications.

So I would have something that, if it's after midnight OR my alarm is enabled, send me notifications. Otherwise, just ignore them.

[freefd]

Hi @maylorian, seems like you're talking about this #131.

[0x2142]

Hi @maylorian - This is on my list & planned to be available via API. I have a little bit of pre-work to do before I get there, but it's on the roadmap for the next release.

[freefd]

@0x2142, I really apologize for such a late comment, but I completely forgot to add the following requirements for API 🙏

• versioning
• openapi compatible
• endpoints for z-pages of readiness and liveness healthchecks from Feature: Healthcheck for the application itself #51

[0x2142]

No worries - happy to have the feedback. The package I'm using for the REST API takes care of the Open API compatibility, so that should be handled already. I was debating whether or not to version it, but I have no strong feelings either way - so I can include that. And I'm okay with including the health checks as well

[freefd]

I was debating whether or not to version it, but I have no strong feelings either way

Every time we wonder about API versioning, the answer must be yes :)

The interface agreement should be fixed most of the time to maintain backwards compatibility for external systems.
If an external system is ready to start using new API features, then in most cases it is a new version of the API that has its own number 🤷‍♂️