An API key is about the simplest possible way to achieve that, and appears to be perfectly adequate in this case.
What do you suggest? SAML?
HTTP is an "API" that has no API keys and all the public web servers in the world seem to manage this without any trouble.
> What do you suggest? SAML?
No authentication required by default -- it's public data. Just impose a reasonable rate limit by IP address and require registration only if someone has a legitimate reason to exceed that.
Um, no. That’s just not true.
Yes you did. When you logged in, they gave you an API key in the form of a cookie that you include with every request.
And it's run at a loss by Y Combinator, which is very, very wealthy. And even hackernews has to pay for cloudflare and mods, on top of hardware, hosting, and traffic.
You can read this website (i.e. make queries against its database) without logging in. Moreover, the main thing the cookie does is not some kind of rate limiting or denial of service protection, it's assigning your username to your posts so that others can't impersonate your account. Various image boards exist that even allow you to post without logging in and they seem to be fine with it.
Yeah, but the sentence I replied to was "nobody signed up for an API key in order to make posts". That claim was false. Being able to read the website is a totally different topic.
It was not. A login cookie isn't an API key. It serves a different purpose, which you can observe on the services that do have an API key and then separately require some other credentials to make posts as a particular user account.
Here's a good way to distinguish them. If I want to make my own app (in this context a web browser), do I have to maintain some intermediary servers that the app makes requests through in order to keep my, the app developer's, API key a secret from the users who are using the app? No, the user only needs their own user account, and only for the things that require a user account, and the service expects for each user to have their own account, rather than each app.
It was. Google "what is an api key", and the first result is
> An application programming interface (API) key is a code used to identify an application or user and is used for authentication in computer applications.
Yes, as you argue, it is indeed used to indentify multi-user applications. It is also used to identify users. It is not as narrow as you thought. Learning something new is a good thing! I'll be abandoning this thread now. If you need to get the last word, go ahead. If you need a victory, then fine- I was wrong all along, you win.
https://news.ycombinator.com/item?id=39094541
Which says:
> A login cookie isn't an API key.
If the first result is authoritative then I guess that sorts it.
But your link was from this site:
https://www.fortinet.com/resources/cyberglossary/api-key
Which is confusing because it also says:
> API keys cannot be used for secure authorization because they are not as secure as authentication tokens. Instead, they identify an application or project that calls an API.
> API keys are generated by the project making a call but cannot be used to identify who created the project.
> API keys are used to identity projects, not the individual users that access a project.
Which certainly implies that API keys identify applications or projects. But it's not that confusing because when the first definition says "user" what it means in context is the application developer.
Using the same definition out of context would lead you to believe that, for example, your browser's user agent string is an API key. It's a code (i.e. symbols) that identifies an application or user (browser fingerprinting) and is used for authentication in computer applications (some sites may require you to authenticate again if your browser fingerprint changes too much). So clearly that definition is too broad without context. If you allow a loose enough definition of "code" it would make your screen resolution an API key because it can be used for fingerprinting in the same way.
> A login cookie isn't an API key.
You.... googled your own comment, and cited it as evidence that my google result was wrong?
I guess I'm done here.
Incorrect. Most large web sites invest in DDOS protection e.g. Cloudflare.
Cloudflare DDOS protection as an example is a lot more sophisticated than merely counting requests per source IP (https://developers.cloudflare.com/ddos-protection/about/how-...).
But API keys aren't any good for that anyway because if someone is just trying to overload your service by brute force, they can send requests regardless of whether the keys are valid and still use up all your bandwidth sending error responses or your CPU/memory opening new connections prior to validating the API keys, and to avoid that you'd still need some kind of DDoS protection.
Where they actually do something is where you're doing accounting, because then if someone wants to send you a million requests, you don't block them, you just process them and send them a bill. Maybe you block them if they reach the point you don't expect them to be able to pay. But if it's a free service that anybody can sign up for as many times as they want then that doesn't do any good because the price is $0 and a rate limit per key is avoided by signing up for arbitrarily many more keys.
Which allows that website (or app) to operate with minimal resources, e.g. by a non-profit or open source project, instead of having to be a for-profit entity which needs some underhanded way to generate revenue in order to display the "free" data.