5 ms·
Good idea, but it does have one failing. When an API key has been compromised (e.g. a developer leaves the company on bad terms), it is much easier to change a
by junto 13y ago
Good idea, but it does have one failing.
When an API key has been compromised (e.g. a developer leaves the company on bad terms), it is much easier to change a randomly generated API key without impacting anything else. Changing an email address is a hassle for the developer, should you need to revoke the 'key' due to misuse by a third party.
Also, this should be obvious, but many people forget to use a secure transport for their APIs, which then leaks private information, such as API keys and other HTTP headers parameters whilst being sent over the wire. SSL is a must for APIs.
- dayglogee 13y agoI suppose you could have your mail system forward all mails with the following format to your real mailbox: api-<guid>@yourdomain.com
- ProblemFactory 13y agoOnce the API gets to the stage where you need authentication, access controls, blocking access, proper rate-limiting or billing, you have outgrown the "email address in request" method. After all, the abuser might not be a former developer, but anyone in the world who knows your email address. But for a first experimental API, it's much better than having no info on who your users are besides an IP address pointing to AWS. And logging API requests to a text file and doing analytics manually with grep is much faster than setting up developer accounts.
- junto 13y agoIndeed, for experimental early stage APIs this is a good idea, where some info is better than none.