anchor.diff:  [[get-requests]]
   === GET and POST requests
   
  -A number of {es} GET APIs--most notably the search API--support a request body. 
  -While the GET action makes sense in the context of retrieving information, 
  +A number of {es} GET APIs--most notably the search API--support a request body.
  +While the GET action makes sense in the context of retrieving information,
   GET requests with a body are not supported by all HTTP libraries.
   All {es} GET APIs that require a body can also be submitted as POST requests.
  -Alternatively, you can pass the request body as the 
  +Alternatively, you can pass the request body as the
   <<api-request-body-query-string, `source` query string parameter>>
   when using GET.
   
  
positive.code: by default. To match hidden data streams and indices using a wildcard
  expression, you must specify the `expand_wildcards` query parameter.
  
  You can create hidden data streams by setting `data_stream.hidden` to `true` in
  the stream's matching <<indices-put-template,index template>>. You can hide
  indices using the <<index-hidden,`index.hidden`>> index setting.
  
negative.code: [[api-compatibility]]
  === REST API version compatibility
  
  Major version upgrades often include a number of breaking changes
  that impact how you interact with {es}.
  While we recommend that you monitor the deprecation logs and
  update applications before upgrading {es},
  having to coordinate the necessary changes can be an impediment to upgrading.
  
  You can enable an existing application to function without modification after
  an upgrade by including API compatibility headers, which tell {es} you are still
  using the previous version of the REST API. Using these headers allows the
  structure of requests and responses to remain the same; it does not guarantee
  the same behavior.
  
  
  You set version compatibility on a per-request basis in the `Content-Type` and `Accept` headers.
  Setting `compatible-with` to the same major version as
  the version you're running has no impact,
  but ensures that the request will still work after {es} is upgraded.
  
  To tell {es} 8.0 you are using the 7.x request and response format,
  set `compatible-with=7`:
  
  [source,sh]
  