根据Rest，如果我们必须检索一些数据，我们应该使用GET，如果它正在创建资源，则应该使用POST。
但是，如果我们必须使用多个参数(超过7-8个(，或者UUID列表，那么我们不应该使用POST而不是GET吗？
避免：
- URL的复杂性
- 纳入任何新领域的未来范围
- URL长度可能会在未来限制我们
- 如果我们不编码我们的URL，那么我们可能会有暴露params的风险(尽管这是最不重要的一点(
谢谢。
当GET的语义符合用例时使用GET；换句话说，当您试图检索某个资源的最新表示形式的副本时。
当没有其他标准化方法支持您需要的语义时，请使用POST。
可以对所有内容使用POST，但您放弃了使用更专业化方法的优势——通用组件执行智能操作的能力，因为它们理解请求的语义。例如，GET具有安全的语义，这意味着通用组件知道它可以在用户需要之前预先获取资源的表示，或者如果没有从服务器获得响应，则自动重复请求。
HTTP为您提供的是通用POST方法的可扩展的改进集合，添加了更具体的约束，以便通用组件可以利用生成的属性。
URL 的复杂性
URL的复杂性其实并不是什么大不了的事，就通用组件而言，URL只是一个不透明的字节序列，恰好遵守某些生产规则。在大多数情况下，web请求的有效目标uri被视为一个原子单元，因此看起来可能是"；对人类来说，复杂根本不会困扰机器(例如，看看你从谷歌主页提交搜索时使用的URL(。
URL长度，这可能会限制我们在未来的
我们有点关心URL长度。RFC 3986没有限制URI的长度，但如果长度远远超出规范，一些通用组件的实现将失败。因此，您可能不想在请求的查询部分包含未桥接的莎士比亚作品的url编码副本。
未来范围包括任何新的领域
同样，这里没有太大区别。向URI模板添加新的可选元素实际上与向消息模板添加新可选元素没有什么不同。
我们可能有暴露参数的风险
我们还需要小心敏感信息——就机器而言，URI是一个标识符；没有特别的理由担心特定的字节序列。这意味着URI可能在静止时公开(在客户端历史记录或书签列表中，在服务器访问日志中(。将敏感信息限制在消息正文中可以减少数据超出预期用途的可能性。
请注意，REST和利用不同的HTTP方法并不是完成有用工作的唯一方法。SOAP(以及最近的gRPC(认为，不同的权衡集合更好——实际上，将HTTP减少到传输，而不是应用程序本身。
根据Rest，我们应该。。。如果正在创建资源，请使用POST。
这是对REST的错误解释。这是一种非常常见的解释，但不正确。POST的语义由RFC 7231定义；它意味着那样，而不是别的。
POST应该只用于创建的建议是一种过度简化的误导。我能找到的最早的参考文献是保罗·普雷斯科特2002年的一篇博客文章；当然，随着RubyonRails的出现，它变得非常流行。
但请记住：REST是万维网的体系结构风格。HTML是网络上最常见的超文本媒体类型，它只支持两种HTTP方法；GET，用于从服务器获取资源表示，POST执行其他所有操作。
如果您有敏感数据，如用户名和/或密码，最好编码为表单参数(键值对(，则也应该使用POST