Both approaches work, but in most API scenarios the token‑bucket (or leaky‑bucket) model gives a smoother experience because it lets legitimate bursts through while still capping the long‑term average rate. Fixed‑window counters are simpler to implement and are fine for low‑traffic services where a hard reset each minute or hour won’t surprise users, but they can cause “burst‑cliff” problems—one request at the end of a window and another right after the reset can double the allowed rate. If you need fine‑grained control (different limits per user, per endpoint, or per time‑of‑day) and want to avoid penalising short spikes, go with a token‑bucket implementation, preferably backed by a fast store like Redis. For a quick prototype or a tiny service where simplicity outweighs the occasional burst penalty, a fixed‑window counter is acceptable, but be ready to switch to a bucket‑style limiter as traffic grows.