Lately I've seen plenty of APIs designed like this:

curl "https://api.somewebsite.com/v1/something&key=YOUR-API-KEY"


Isn't it elementary that passing an API key in a query string as a part of the URL is not secure at least in HTTP.

This is commonly known as a capability URL / secret URL.
It's secure in modern websites but not suitable for all applications and requires significant care to use.
You can find an excellent overview of their advantages, risks and best practices in this page by W3C.

It's meaningless to talk about security without specifying a threat model. Here are a couple that come to mind:

1: A passive attacker on the network (eavesdroping)
2: An active attacker on the network (can change packets at will, mitm, etc)
3: A shoulder-surfer
4: An attacker with physical access to your computer / elevated privileges
5: another user of your computer (regular privileges / remote access)
6: the user itself (as in protecting a API key)


Regarding network attacks (1 and 2), capability URLs are perfectly secure, provided you're using HTTPS (it's 2016, you shouldn't be using HTTP anymore!).
While the hostname of a server is sent in plaintext over the network, the actual URL is encrypted before being sent to the server - as it's part of the GET request, which only occurs after the TLS handshake.

Regarding shoulder-surfing (3), a capability URL with enough entropy is secure against a casual attack, but not against a dedicated attacker·
As an example, a google docs URL:

https://docs.google.com/document/d/5BPuCpxGkVOxkjTG0QrS-JoaImEE-kNAi0Ma9DP1gy

Good luck remembering that while passing by a co-worker's screen!
Obviously, if your attacker has a camera and can take a picture without being noticed, it's an entirely different matter.
If the information you're securing can put your users at risk of this kind of attack, you should probably not use a capability URL. Or at least mitigate the issue by doing a HTTP redirect away from the capability URL, so it's only on screen for a few seconds,

Regarding an attacker with elevated privileges on your computer (4), a capability URL is not less secure than a long password or even a client-side TLS certificate - as all of those are actually completely insecure, and there's not much you can do about that.
An attacker with regular privileges (5), on the other hand, should not be able to learn the capability URL as well, as long as you follow good security practices for your OS. Your files (particularly browser history) should not be readable by other users.
If you share your computer account with other people, this is also horribly insecure. A good rule of thumb for shared computers is to not use them to access any information you'd not speak out loud in the street.

For protecting API keys (6, which was the point of this question), a capability URL is also as secure as a less visible mechanism (such as an AJAX POST). Anyone that has an use for an API key will know how to use the browser debug mode to get the key.
It's not reasonable to send someone a secret and expect them not to look at it!

Some people have asked about the risks on the server side.
It's not useful to treat server-side risks by threat modelling in this scenario. From a user perspective, you really have to treat the server as a trusted third party, as if your adversary has internal network access on the server side, there's really nothing you can do (very much like a privileged attacker on the client's computer, i.e. threat model 4 above).
Instead of modelling attacks, I'll outline common risks of unintentional secret exposure.
The most common concern with using capability URLs on the server side is that both HTTP server and reverse proxies keep logs, and the URL is very often included.
Another possibility is that the capability URLs could be generated in a predictable way - either because of a flawed implementation, a insecure PRNG, or giving insufficient entropy when seeding it.
There are also many caveats that have to be taken into consideration when designing a site that uses capability URLs.
In practice, for sites with dynamic content, it's quite hard to get everything done securely - both Google and Dropbox botched it in the past, as mentioned on this answer

Finally, capability URLs have a couple of advantages over other authentication methods:

They are extremely easy to use (just click the link, as opposed to entering your email and password)
They don't require the server / service to securely store sensitive user credentials
They are easily shareable without risks, unlike sharing you password (which you reuse for 50 other sites).

