Proposal: replace `Authorization` header with `api-key`

[mycargus]

Observed behavior

The rx gem requires an Authorization request header for the /deep endpoint to contain a Datadog GUID.

Expected behavior

The health checks standard at Instructure requires an api-key request header for the /deep endpoint.

Background info

We (testops and contributing engineers) initially thought to send the Datadog GUID through the Authorization header, as the rx gem does today, but we ended up settling on an api-key header for two reasons:

1. Injecting an Authorization request header with a string key value doesn’t follow IETF’s HTTP specifications for the Authorization header as it has no appropriate auth-scheme and no encoding. While the Deep “api-key” header is an authorization mechanism for the /deep endpoint, we don’t want to require a practice that breaks IETF standards. HTTPS secures the api key.
2. Is it really a big deal if we use a malformed Authorization header for internal use, anyway? Probably not. But we do have plans for a refreshed statushistory.instructure.com site that sends requests to all SKU /deep endpoints, so having a universal header implementation will make that site much simpler and easier to build.

Proposal

Replace the Authorization request header requirement with the api-key request header requirement.

I think it'd be a simple change in the code. I'm happy to submit that PR for your review. What do you think?

[zachpendleton]

I don't have a problem with it; what do you think about checking Authorization and api-key vs. replacing Authorization? I know the library has some consumers outside of INST who may be relying on the existing behavior.

[mycargus]

👍 love it! I'll submit a PR. Thanks!