A public-health lab integration must send an API credential on each request. Where should that credential be carried in a typical REST call?
Select an answer to reveal the explanation.
Short Explanation
You can think of the Authorization header as the badge you show at the clinic door with every request. API tokens belong there; putting them in the URL path, an undocumented JSON comment, or a public wiki risks exposure or unreliable access.
Full Explanation
A public-health lab integration must present its credential with each REST request so the API can authenticate the caller before returning protected data. Carry the issued API token in the Authorization header, using the scheme documented by the lab gateway. This is the standard choice among the listed options and keeps the credential out of the resource identifier and JSON body, both of which may be captured by logging or support tools. Putting the credential in the URL path after the lab assay code fails because URLs can appear in access logs, browser history, referrer headers, or shared bookmarks, exposing the secret. An undocumented comment field inside the JSON body fails because it is not an agreed authentication mechanism; gateways and clients may ignore it, while body logging can retain its contents. A publicly shared wiki page fails because the credential is exposed to anyone with access and manual copying is unreliable and difficult to audit. Exam caveat: the Authorization header is the tested location, but the exact scheme must follow the lab gateway’s documentation; the header does not replace HTTPS. Practical check: verify that the client sends Authorization on every request, that logs redact it, and that a request without the token is rejected while a valid request succeeds.