One good bit of advice I have seen for people who are just starting out with publishing an API: require a "developer email" parameter in the request instead of API key.
Yes, it could be spoofed or faked. But:
* You can detect honest, accidental excessive usage and follow up by email,
* You can block new email addresses but keep the API up for existing users if hit by a randomised bot,
* You can follow up with developers, and interview them to see what they are using the API for,
* There is an obvious way to get in touch with developers to tell them about API changes,
* And you can start out with this by just logging requests to a database/file/cache, without building a full "developer portal".
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
One good bit of advice I have seen for people who are just starting out with publishing an API: require a "developer email" parameter in the request instead of API key.
Yes, it could be spoofed or faked. But:
* You can detect honest, accidental excessive usage and follow up by email,
* You can block new email addresses but keep the API up for existing users if hit by a randomised bot,
* You can follow up with developers, and interview them to see what they are using the API for,
* There is an obvious way to get in touch with developers to tell them about API changes,
* And you can start out with this by just logging requests to a database/file/cache, without building a full "developer portal".
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