Reasonable. However, I don’t think many user will see this advice here. I suggest adding it to the docs. And maybe it would make sense for you to customize the 502 error response to include information on the problem and how user can solve it from themselves and for others.
I wonder what kind of limit would help. Limiting to one update in 5 or 15 minutes would probably just make people schedule their cron jobs to */5 or */15, contributing to rush hour problem. Something like once per hour might get people to strive for more frequent checks without no-op updates. But it seems like a rather harsh limit.
ddclient does avoid no-ops. When running in daemon mode, it seems to work at a fixed interval, but starting from the point in time when the daemon was started - which should be essentially random.
Systemd timers support randomized delays out of the box. With cron you’d have to get a little creative, but it’s doable.
It’s all there, but some people don’t use it. Why? Some speculation:
Personally, I did not want to bother with the complexity of ddclient and thought a simple curl request would be much easier. And it actually is. For me, that is, but not for you. I was not aware of the implications of my approach. A note on the cost of no-ops in the docs would have made me consider better options.
@ole mentioned issues with ddclient and IPv6 as the motivation for rolling their own python script. Maybe the docs could provided a configuration example for ddclient that better covers the most common use cases, fewer people would look for home-brew alternatives.
Adding a few examples on how to randomize the timers and cron jobs to the docs might help with the rush hour problem.
I realize that documenting how to use basic system software like cron and systemd timers is not really in the scope of your API documentation. But I think it may be worth it. If you want people to behave in a certain way, make it as easy as possible from them to do so.