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 <[log in to unmask]> wrote:
>
>> On Dec 3, 2013, at 4:18 AM, Ross Singer <[log in to unmask]> 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
>>
>
>