An OpenBSD developer and the one-man-band behind Pushover gives some advice after 10 years of running a public HTTP API.
It’s interesting as big companies are happy to publish articles about all the fancy stuff they developed to run some API, but you don’t always hear from a sole developer running a service for such a long time.
some esoteric devices and plugins don’t support them. In fact, some don’t even support HTTP POST properly and will only be able to put form parameters in the URL query string (though you still need to insist on requiring a proper POST method, don’t be an animal).
This gave me a chuckle. Good, practical advice for smaller APIs. Bigger orgs are likely to have distributed tracing etc but for a one man show it’s good to have input on what’s proved actually useful and necessary.
I’ve run a (nowhere near as popular) public API for just about 10 years now. Definitely relate to the bit where he mentions people simply retrying the same request when they get an error. 😂
I get a lot of students using the API for learning projects, which is great! But it also means my rate limiting is more often protecting my server from accidental infinite loops, rather than anything purposely abusive.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
This gave me a chuckle. Good, practical advice for smaller APIs. Bigger orgs are likely to have distributed tracing etc but for a one man show it’s good to have input on what’s proved actually useful and necessary.
Interesting article, thanks for sharing!
I’ve run a (nowhere near as popular) public API for just about 10 years now. Definitely relate to the bit where he mentions people simply retrying the same request when they get an error. 😂
I get a lot of students using the API for learning projects, which is great! But it also means my rate limiting is more often protecting my server from accidental infinite loops, rather than anything purposely abusive.
This was a super interesting read