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.
Once 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.
Comments
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.
Once 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.
Indeed, for experimental early stage APIs this is a good idea, where some info is better than none.
I suppose you could have your mail system forward all mails with the following format to your real mailbox: api-<guid>@yourdomain.com