title: Why would HTTP content negotiation be preferred to explicit parameters in an API scenario?
body: <p><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation" rel="nofollow noreferrer">HTTP content negotiation</a> can be used to make client and server agree on a data format and language. Maybe you're interested in my previous question (<a href="https://stackoverflow.com/questions/44720631/is-http-content-negotiation-being-used-by-browsers-and-servers-in-practice">Is HTTP content negotiation being used by browsers and servers in practice?</a>) but it's not necessary to read.</p>
  
  <p><strong>Does this concept really make sense when developing an HTTP-based API?</strong> (An API is a web service that is not used by end users. It's called exclusively in a programmatic way.)</p>
  
  <p>An alternative to content negotiation are "regular" parameters (e.g. <code>http://example.org/myService?someParam=1234&amp;lang=en&amp;format=xml</code>).</p>
  
  <p>Most client-side frameworks make it very easy to call a web service and send parameters. It is often much harder to configure special HTTP headers. It seems to be more work to use HTTP content negotiation.</p>
  
  <p>At the same time there is no need to <em>negotiate</em>. The client will be programmed in such a way that it knows what formats and languages are available. Therefore, it will only make valid calls in this regard and get exactly what it wanted.</p>
  
  <p>If the server wants to decline a call it can send an application-level error instead of an HTTP error. Application-level errors are, in my experience, easier to handle. You need that code anyway. You don't necessarily ever need to interpret HTTP errors. You can just treat all of them as a generic failure.</p>
  
  <p>Content negotiation seems to fit the REST philosophy well but I'm more interested in concrete costs and benefits.</p>
  
  <p><strong>In what way is HTTP content negotiation superior to just adding an API parameter?</strong></p>