Thank you Steve for highlighting the short comings of my epilogue. I was attempting to provide a colloquial explanation of RFC 7231, specifically section 3.1.1.5 on content-type
, and the assymmetry between client provided content-type
in section 4.3.1 on GET
requests (1) versus servers expecting content-type
in section 4.3.3 on POST
requests (2). Particularly within the context that content-type: application/json
has evolved to become the defacto standard for querying server APIs; which in turn requires serializing byte data.
Hopefully you won’t exhaust yourself on the never ending supply of people who are wrong on the internet.
- Roughly the
content-type
in aGET
says “when you send me data I will interpret it as…So be advised when preparing your response.” (clients discretion). - Conversely the
content-type
in aPOST
says “I’m sending you data that I interpret as…Feel free to reject it if that is not what you want or can safely handle.” (servers discretion).