
An Alternative to Required API Keys - EzGraphs
http://www.jamesward.com/2013/07/29/an-alternative-to-required-api-keys
======
ProblemFactory
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".

~~~
junto
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.

~~~
ProblemFactory
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.

~~~
junto
Indeed, for experimental early stage APIs this is a good idea, where some info
is better than none.

------
TillE
> Rate limiting is one approach but it is easily gamed.

Is it? Simple IP-based rate limiting seems quite effective to all but the most
determined abuser.

~~~
lazyjones
> _Simple IP-based rate limiting seems quite effective to all but the most
> determined abuser._

Most (noticeable) abusers are quite determined. They will try Tor, then
various anonymizer proxies (forcing you to block all of them or give up), then
sometimes Amazon EC2 instances or other VPS, or large public proxies / ISP
proxies that you cannot block. In Germany, they can also use cheap DSL where
they can switch to new IP addresses almost instantaneously (T-Online is a
godsend for abusers/scrapers).

~~~
dubcanada
What's to stop them from creating a bit that creates API keys every 5 minutes?

~~~
iaskwhy
A delay on the API key generation or approval?

------
martin-adams
To me it seems like hanging would be more of a deterrent than failing requests
as developers could simply retry a request on a simulated failure.

Some developers could even try to fire multiple requests and use the fastest
one, effectively reducing the failure rate to the app.

It an interesting problem to solve. The one that I would like to see a
solution on is allowing end users interact directly with a third party service
without exposing the API key or requiring the to do any authentication.

~~~
jsharpe
Another approach to discourage use in production would be to randomly return
incorrect or garbled data. It's still easy to use for learning, but would lead
to embarrassing errors or omissions if used for something real.

~~~
martin-adams
Maybe, but that would just result in less trust in quality of the service.
Which errors and hangs would do also.

I'd rather see simulated data if it's purely for development purposes. You
would have far more control over the conditions you need to test.

------
onion2k
If you're trying to put people off abusing it, wouldn't randomly failing make
the situation worse? People will just code apps to try the request again until
it doesn't. It'd be like inviting people to DDoS your API. So long as the
display bit is asynchronous then the user will just see a spinner until it's
worked and the results are sent across.

------
chiph
_Required keys make it much harder for developers to learn new things._

Really? You fill out a form, click submit, get your key via email soon after.
Or at worst, the following Monday. IMO, that's not a lot of friction.

~~~
pavel_lishin
> Or at worst, the following Monday.

For someone just starting out, having to wait the entire weekend that you
planned to use for studying is pretty much a dead end.

~~~
btgeekboy
Tell that to the Google Cast team. Saturday morning: "Hmm, how does this stuff
work? Oh, I've got to get a key..." Monday night, 11PM: "Here's your key!"

------
moron4hire
how hard is it to run a second, smaller server for "learning" that doesn't get
rate limited but also doesn't have full access? Maybe it even only has access
to a fake data set, no real data.

