Return 401 Unauthorized when "key" parameter is missing

[christiandeange]

Any API endpoint will currently return 200 OK, even when the API key parameter is missing. Wouldn't it make sense to indicate there is a client error if the request was not valid?

[KartikTalwar]

Yeah, I've debated this for a while.. The meta key does indicate the proper http status but the HTTP headers don't. One of the reasons was that the JSON is always returned even if the endpoint doesn't exist with the error in the meta key. So if people are just checking response code != 200, you might not be able to determine a 5xx bad api request error from the server being down (compared to just reading the json and double checking).

I keep flipping sides on this because I'd like to be consistent with other services but at the same time I feel like the current setup is a little more informational.

I'll let @nathanv decide

[christiandeange]

I think for clients it makes sense to check the meta data, but sometimes there's other processes that depend on HTTP status codes. Like if I query the API through some other library (or even a browser), a 200 OK response might be cached, even though the data returned isn't valid.

Also it's much easier to just check the response code and try to interpret the result from that, rather than having to consume the entire input stream and then parse out a Json object.

[KartikTalwar]

yeah fair enough. @nathanv will be implementing this shortly

[KartikTalwar]

The HTTP status codes now reflect the API error codes