I do frequently see API keys in header, it is a frequent pattern.
Anything that requires things in the header, in my experience makes the
API more 'expensive' to develop against. I'm not sure it is "okay to
require headers".
Which is why I suggested allowing format specification in the URL, not
just conneg headers. And is also, actually, why I expressed admiration
for google's pattern of allowing X requests a day without an api key.
Both things allow you to play with the api in a browser without headers.
If you are requiring a cryptographic signature (ala HMAC) for your
access control, you can't feasibly play with it in a browser anyway, it
doesn't matter whether it's supplied in headers or query params. And
(inconvenient) HMAC probably is the only actually secure way to do api
access control, depending on what level of security is called for.
On 12/2/13 1:03 PM, Robert Sanderson wrote:
To be (more) controversial...
If it's okay to require headers, why can't API keys go in a header rather
than the URL.
Then it's just the same as content negotiation, it seems to me. You send a
header and get a different response from the same URI.
Rob
On Mon, Dec 2, 2013 at 10:57 AM, Edward Summers <[email protected]> wrote:
On Dec 3, 2013, at 4:18 AM, Ross Singer <[email protected]> wrote:
I'm not going to defend API keys, but not all APIs are open or free. You
need to have *some* way to track usage.
A key (haha) thing that keys also provide is an opportunity to have a
conversation with the user of your api: who are they, how could you get in
touch with them, what are they doing with the API, what would they like to
do with the API, what doesn’t work? These questions are difficult to ask if
they are just a IP address in your access log.
//Ed
