If such a parameter should go into a custom header or the query string is mostly a question of developer experience.
I tend to favor query strings for a few reasons. Aside from the theological beliefs, a few of the reasons are concrete or footgun-avoidance :)
If your API is or can be called cross-domain, adding a custom header will require browsers to do a CORS preflight check where they might have been able to omit it before--making requests to your API slower!
Also, if you're cross-origin, you need to remember to add the header to your Access-Control-Allow-Headers as appropriate.
If you want your endpoint to be cached, you also need to remember to add the new header in the Vary headers in your response.
Query strings generally show up better by default in your logging and analytic tools.
If your API is or can be called cross-domain, adding a custom header will require browsers to do a CORS preflight check where they might have been able to omit it before--making requests to your API slower!
Although that’s technically true, you’ll most likely trigger the CORS preflight check anyway due to the Content-Type as it’s quite unlikely you’ll be using one of the plain-text or form data types.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I tend to favor query strings for a few reasons. Aside from the theological beliefs, a few of the reasons are concrete or footgun-avoidance :)
Although that’s technically true, you’ll most likely trigger the CORS preflight check anyway due to the Content-Type as it’s quite unlikely you’ll be using one of the plain-text or form data types.