When do you use custom HTTP headers in the request part of a REST API ?
Example:
Would you ever use
GET /orders/view (custom HTTP header) CLIENT_ID: 23
instead of
GET /orders/view/client_id/23 or GET /orders/view/?client_id=23
Headers carry meta info, parameters carry actual data. HTTP Servers will automatically un-escape/decode parameter names/values. This does not apply to header names/values. Header names/values need to be manually escaped/encoded at client side and be manually un-escaped/decoded at server side.
As mentioned, custom headers are great for troubleshooting, informational purposes, and even implementing particular logic on the server side. For example, KeyCDN makes use of the X-Cache header to let users know whether or not an asset has been delivered from an edge server or from the origin server.
Custom Headers are for troubleshooting, informational purposes, and specific server-side logic. For example, to send a GET request with a custom header name, you can use the "X-Real-IP" header, which defines the client's IP address. For a load balancer service, "client" is the last remote host.
The URL indicates the resource itself. A "client" is a resource that can be acted upon, so should be part of the base url: /orders/view/client/23
.
Parameters are just that, to parameterize access to the resource. This especially comes into play with posts and searches: /orders/find?q=blahblah&sort=foo
. There's a fine line between parameters and sub-resources: /orders/view/client/23/active versus /orders/view/client/23?show=active
. I recommend the sub-resource style and reserve parameters for searches.
Since each endpoint REpresents a State Transfer (to mangle the mnemonic), custom headers should only be used for things that don't involve the name of the resource (the url), the state of the resource (the body), or parameters directly affecting the resource (parameters). That leaves true metadata about the request for custom headers.
HTTP has a very wide selection of headers that cover most everything you'll need. Where I've seen custom headers come up is in a system to system request operating on behalf of a user. The proxy system will validate the user and add "X-User: userid
" to the headers and use the system credentials to hit the endpoint. The receiving system validates that the system credentials are authorized to act on behalf of the user, then validate that the user is authorized to perform the action.
I would only use a custom header when there is no other way to pass information by standard or convention. Darren102 is explaining the typical way to pass that value. Your Api will be much more friendly by using typical patterns verse using custom headers.That's not to say you won't have a case to use them, just that they should be the last resort and something not already handled by the HTTP spec.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With