0

I was trying to find if there is some kind of reference about what type of informations are important to be passed on the HTTP Header.

I understand that some information seems natural to be there, like the Authorization, Content-Type, Accept, and so on.

Some articles explains that the HTTP Header are used to send optional or additional informations about the request.

What I understand about the HTTP Header objetive is: send informations that are useful for all (or almost all) requests made to the API.

But all this continues to be very vague to me.

Many APIs use them to pass additional information about the authorized user and, of course, the Authorization header. But pass the authorization/user informations on HTTP Headers is a generalized concept for me. I'm looking for an explanation that could clarify the use (or not) for specific API problems.

Per example, see this question. I'm sure that the platform and user could be send through the HTTP Headers (even I prefer the URL), but if the platform and user reference are used for all endpoints on the API, maybe the HTTP Header could be a reasonable place to put them.

Is there some reference about what kind of situations the HTTP Header could be used? What you guys understand about the HTTP Header use?

Nicholas Shanks
  • 337
  • 2
  • 12
Dherik
  • 2,406
  • 20
  • 33
  • 6
    You should use HTTP headers when information is related to communication itself rather than the matter of request. So things like encoding, caching, language, authorization are good examples of communication details. – Tomasz Maciejewski Mar 28 '18 at 09:40
  • @kadiii, this kind of information I'm aware. My question is about use the HTTP Headers to resolve API specific problems (as described in my example). – Dherik Mar 28 '18 at 12:34
  • Have you checked the [RFC](https://tools.ietf.org/html/rfc2616#section-4.2)? – Laiv Mar 28 '18 at 12:48
  • @Laiv, it's very generic for me: `The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server.` – Dherik Mar 28 '18 at 12:52
  • Headers are expected to condition the behaviour of the IPC. Think in `Content-type` informing the input data format and the `Accept`informing the accepted format of the response. Or the `Authorization` informing that an additional procedure (security) should be accounted by the system. Or the conditional headers [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since) and such. Headers impacts on the IPC itself. Most of the things informed through HTTP headers are traversals in any architecture (security, cache, message formatting,...) – Laiv Mar 28 '18 at 13:04
  • 2
    @Dherik The definition is generic like in such a specifications but also very precise. You can include additional information *about* the request (like e.g. encoding, authorization,) and information *about the client* itself (like e.g. Accept Type). – Tomasz Maciejewski Mar 28 '18 at 13:06
  • @Laiv, yes, until here is clear to me. I gave an [example](https://softwareengineering.stackexchange.com/q/368424/172464) where some informations about the request could be on HTTP Header , but this infos are not related to the architecture or authorization informations. This is the point where my question starts: HTTP Headers could be used to resolve **specific** API problems, providing informations that are not related with the user or authorization (per example)? How identify this cases? I will provide more details on my question. – Dherik Mar 28 '18 at 13:13
  • 1
    Headers don't provide information related to the "business" (ideally). They rather provide information and instructions related to the "act" of exchanging messages. *client: I do request the URI and I expect to get it in JSON format, only if the response has been modified since. And please, don't cache further responses to this URI. Server: Ok, I accept your request as soon as you provide me with the message in JSON format and you are authorized* – Laiv Mar 28 '18 at 13:26
  • @Laiv, very nice explanation. Could be an answer. – Dherik Mar 28 '18 at 13:37
  • The writing style of all the RFCs is very particular, with special words like CAN, MAY and SHOULD having very precise and concrete meanings. Just because you CAN do something, does not mean that you SHOULD. But you MAY, if you KNOW EXACTLY WHAT YOU ARE DOING. If not, keep reading the RFCs... –  Apr 05 '18 at 13:16
  • 2
    Possible duplicate of [What belongs in an HTTP request header vs the request body?](https://softwareengineering.stackexchange.com/questions/277343/what-belongs-in-an-http-request-header-vs-the-request-body) – Dherik Sep 10 '18 at 19:40

0 Answers0