Hello.
Yesterday, during an active print i send by mistake an G28 command via the API.
Was a little surprised that the printer fullfills the task (G28) during the print.
Is this now:
a. Dont do stupid things... request first the state of the printer and then send the API command.
b. Looks like a bug in the firmware "Klipper". Please open an bug report.
c. Looks like a bug in Octoprint. Please open an bug report.
Regards
Classic case of a) 
There are valid reasons for a G28 during an active print - e.g. the homing routine contained in your sliced file right at the start. Or a limited rehome on axis as recovery move after a position loss. Removing the ability to send a G28 after the first minute or first hundred lines of a print or so is bound to ruin the day of someone out there, though it could be done via a plugin. That would be why this isn't b) or c).
And there's even something else that speaks against b) - there's no standardized way to tell firmware "hey, I'm now going to start a print, consider that ongoing until I tell you otherwise" that works across firmware variants (honestly, with the fragmentation that's going on there I'm sometimes surprised that anything works at all). So how would firmware be able to know whether the G28 you just sent came during a print vs just at the start vs outside of a print?
Thanks a lot for the explanation. 
Makes 100% sense from this point of view.