Rest API Support

[iamMHZ]

• I'm submitting a ...

  • bug report
  • feature request
  • support request

• What is the current behavior?
  The Current way of adding a configuration is by editing a couple of env files which is a really good way of managing backups for a
  small number of containers. The drawback of this approach appears when you have multiple schedules and wanna be able to edit them from the app container which makes it really messy for you to edit multiple env files.

• What is the new feature behavior?
  It would be really nice to support Rest APIs. For example, having an API for changing schedulers of backup containers, makes deployment easier and faster.

[m90]

Thank you for this proposal. I've got a few questions for my understanding about how such a thing could look like:

• where would such a setup persist its configuration? Would that mean we'd have to start using a SQLite database or similar?
• is there some sort of standard for handling configuration over a REST API or would that mean we'd have to model some tailor made schema for this tool?
• changing a backup schedule currently requires restarting the cron daemon. If changing this in a running container were to be supported, it would mean we'd have to move from cron to some other (native Go) tool
• how would this approach to configuration work in parallel to the existing approach. Would they be mutually exclusive or could you use both approaches?

[iamMHZ]

• Yeah we need to start using a database for storing backup plans, so the end user can have CRUD functionality on backup plans.
• We can follow the REST guidelines and standards.
• One of the hinders is restarting the cron daemon whenever there is a change on a backup schedule. Just off the top of my head, there might be third-party packages in GO for creating and updating cron jobs. I have worked with some packages for scheduling jobs In python, things like apscheduler.
• It's hard to say, for sure there are things to consider and think about based on the API stuff that we create.

[m90]

Although I do like the idea, I am not sure if having to add persistence isn't adding too much complexity for a rather simple tool like this. I'll leave the issue open and maybe think about it again if a v3 is ever on the horizon (which would mean things could fundamentally change), see #80

Thanks for your input, it's much appreciated.

[m90]

This was discussed again in #329, and I don't think this will ever be implemented. Having persistence in a backup tool would require users to come up with backup solutions for their backup tool, which is kind of odd. Other means of configuration are probably more fitting in this context.