在上述1和2之间选择的最佳做法和考虑因素是什么？
通常，内容主体用于要上传/下载到服务器/从服务器下载的数据，查询参数用于指定所请求的确切数据。例如，当你上传一个文件时，你需要指定文件名、MIME类型等。但是当你获取文件列表时，你可以使用查询参数来过滤文件的某些属性。通常，查询参数是查询的属性而不是数据的属性。
当然，这不是一个严格的规则-你可以用任何你觉得更合适/更适合你的方式来实现它。
您可能还需要检查wikipedia article about query string，尤其是前两段。

我假设你正在谈论POST/PUT请求。从语义上讲，请求主体应该包含您正在发布或修补的数据。
查询字符串，作为URL（URI）的一部分，它用于识别您正在发布或修补的资源。
你问的是最佳实践，下面的语义是我的。当然，使用你的经验法则应该是可行的，特别是如果你使用的web框架将其抽象为 parameters。
你最知道：

• 某些Web服务器对URI的长度有限制。
• 您可以使用CURL在请求体中发送参数。
• 发送数据的位置不应该影响调试。

以下是我的经验法则...

何时使用身体：

• 当参数没有扁平键：值结构时
• 如果值不是人类可读的，例如序列化的二进制数据，
• 当你有大量的论点时
  何时使用查询字符串：
• 当参数是您希望在调试时看到的参数
• 当你想在开发代码时手动调用它们时，例如：关于curl
• 当参数在许多Web服务中通用时
• 当您已经发送了不同的内容类型，如application/octet-stream

注意，你可以混合和匹配-把常见的，那些应该在查询字符串中调试，并抛出所有其余的JSON。

我一直使用的理由是，因为POST，PUT和PATCH可能有包含客户可能认为专有信息的有效负载，最佳实践是将这些方法的所有有效负载放在请求主体中，而不是URL参数中，因为很可能在某个地方，不知何故，URL文本由您的Web服务器记录，您不希望客户数据以纯文本形式飞溅到日志文件系统中。
对于GET或DELETE或任何其他REST操作来说，通过URL的潜在暴露不是问题。

根据R. Daigneau，服务可以利用Tolerant Reader模式。这可确保在接收到的消息或媒体类型中的某些内容未知或数据结构发生变化时，服务正常运行。
软件可能会随着时间的推移由小块增量开发，但系统设计会自然发展。不幸的是，当任何涉众向消息中添加、更改或删除数据项时，它引入了中断更改的可能性。该服务必须向前兼容，并在一定条件下接受它不完全理解的内容。只有当消息内容明显违反业务规则时，才会抛出警告。
作为对其他答案的补充，我们可以想象一个服务，它接受来自请求主体和查询字符串的消息数据，用于同一个请求项表示。这与不断发展的客户相适应。