Introducing a Fair Use policy #97
Description
When @tathamoddie and I created httpstat.us back in 2011 it was mostly to scratch an itch we had, and we had no major plans for it beyond writing the code.
Fast forward a decade, the service is still up and doing more traffic that we'd ever anticipated. While we never really promoted it or did any pushes on it, it has picked up a lot of users and been used for a wide variety of scenarios.
But with success, comes issues. We have some very clear performance issues, which are discussed in #89 and for httpstat.us to continue to provide the service people want, it's time to properly look at addressing them.
Introducing a fair use policy
Up until now the service just is, you hit an endpoint and you'll the right response. We've never done anything to describe how you should use the service, we've just believed that people will be fair to everyone. But as I've been diving more into the logs around how the service is used; it's become clear that we need to have some documented guidelines on what constitutes fair use.
The first time we tackled this was with dbbda4a, which killed a particular endpoint that was being abused, or at least, being used in a way that we considered abuse.
Unfortunately, it appears that we've hit the limit on how effective that hack is and it's time to do a more permanent solution.
Addressing performance issues
There are a few things that we'll be tackling over the next little while in an attempt to address the performance issues we're experiencing and instigating the fair use policy.
First, we'll revisit PR #91 and get the codebase upgraded to .NET 5. It's about time to move on from the .NET Framework, it's served us well for a decade, but it's showing its age and .NET 5 opens up the door to a lot of performance improvements. It'll also make it easier for people who wish to self-host by having containerisation as a viable option, something that .NET Framework can't offer us.
Secondly, introducing an API token combined with rate limiting.
Access tokens and rate limiting
Complete unbridled access has served us well for the past decade but going forward we need something smarter, and this will be in the form of rate limiting.
With no token provided, users will be limited in the number of requests per minute they can make to the service. We don't have the figured on what it'll be yet, but the intent is to have it without the bounds of what we believe to be fair use.
If you need to make more requests than that, you'll be expected to register and provide an access token as part of the request. We don't have the final implementation sorted out, but it'll be a case of providing a token via either a header or parameter on the request. Again, this will be subject to a level of fair use but is more for accountability as we presently have no way to monitor for potential abuse and as I've stated, the whole point of this is to ensure it's fair for everyone.
Conclusion
The fundamental goal of httpstat.us hasn't changed, we want to make an easy-to-use site for testing how different status codes can be handled in your applications, but we're at a point where it's time to instigate some restrictions to avoid abuse and keep the service available for everyone.
There isn't a timeline for this happening, but we'll make sure that things are communicated as well as they can be, given we've got no way to contact users! 😅
If you have any questions, comments, or concerns, sound off in the comments below.