在我的框架的设计过程中，我想到将POST和GET参数合并为一个$ parameters变量。
开发人员的优势：框架过滤所有参数值以再次保护XSS攻击（即有趣的孩子插入错误的javascript代码以将访问者重定向到垃圾邮件站点）以及其他类型的有用验证/过滤。
但是像往常一样：分离POST和GET是否有任何真正的优势，而不是因为它们来自不同的来源它们只是不同？
我的意思是：这有关系吗？当POST参数与GET参数同名时，两者都真的被使用，它会在任何时候都是“好设计”吗？在我看来这很丑，但也许有人有一个很好的解释为什么我甚至不应该尝试合并POST和GET。
我认为POST在任何情况下都会覆盖GET。我希望得到诚实的答案： - ）
答案 0 :(得分：5)
POST和GET请求具有不同的语义。 Wikipedia上有简短说明。基本上是GET请求
不应用于导致副作用的操作，例如使用它在Web应用程序中执行操作。其中一个原因是机器人或爬虫可以任意使用GET，这不应该考虑请求应该产生的副作用。
请注意，HTTP协议不强制执行此操作，这是您的应用程序必须确保的。因此，您应该在框架中分离不同的HTTP谓词。
如果GET请求不是简单地返回具有上述限制的资源，可能会发生什么情况：Well-Intentioned Destruction。
答案 1 :(得分：3)
我认为每个人都忽略了你的问题（或者我只是误解了它。）你不是在问GET / POST之间的区别，你想知道它对于框架是好还是坏您正在构建以自动将这两者的结果合并为一个安全变量。 .Net和PHP都这样做，所以我不明白为什么不这样做。
在PHP中，您可以使用$_GET或$_POST来表示特定方法，或只使用$_REQUEST。与.Net，Request.QueryString和Request.Form vs Request相同。如果有人有理由只获得POST / GET，那么变量仍然存在。
答案 2 :(得分：2)
在某些情况下，接受GET而不是帖子会让您更容易受到CSRF攻击。然而，这并不是一个严格的规则，即使在接受POST时你也应采取措施防止CSRF。
答案 3 :(得分：2)
GET查询可以加入书签，链接到浏览器的历史记录并保存。这可能是好事也可能是坏事;例如，您的用户不希望其他人看到他们访问过example.com/?password=jigglypuff，或者有人欺骗点击链接example.com/?changepasswordto=irh4x0r
答案 4 :(得分：1)
我相信流行的Ruby on Rails框架将它们组合成params变量（技术上是一种方法......），但也允许您通过其他方式访问原始的GET或POST参数。
在我的代码中，我将两者结合起来，但还没有遇到任何问题。
答案 5 :(得分：1)
来自W3：
9.1.1安全方法
执行者应该意识到这一点 软件代表他们的用户 互联网上的互动，和 应该小心允许用户 注意他们可能采取的任何行动 拿出可能出乎意料的 对自己或他人的意义。
特别是，惯例已经 建立了GET和HEAD 方法不应该有 采取行动的重要性 而不是检索。这些方法应该 被认为是“安全的”。这允许用户 代理人代表其他方法， 例如POST，PUT和DELETE，在 特殊的方式，使用户成为 意识到可能的事实 正在要求采取不安全行动。
当然，这是不可能的 确保服务器没有 产生副作用的结果 执行GET请求;事实上， 一些动态资源考虑到了 特征。重要的区别 这是用户没有请求 副作用，所以不能 要对他们负责。 9.1.2幂等方法
方法也可以具有的属性 “幂等”在那里（除了 错误或到期问题） N的副作用> 0相同 请求与单个请求相同 请求。方法GET，HEAD，PUT 和DELETE共享此属性。也， OPTIONS和TRACE应该是方法 没有副作用，等等 本质上是幂等的。
然而，有可能是一个 几个请求的序列是非 即使所有的方法都是幂等的 按顺序执行的是 幂等。 （序列是幂等的 如果单个执行整个 序列总是产生一个结果 重新执行不会改变 该序列的全部或部分。） 例如，序列是非幂等的 如果它的结果取决于一个值 后来修改了同样的 序列。
从不产生副作用的序列 根据定义，是幂等的（提供 没有并发操作 正在同一套上执行 资源）。
所以基本上GET意图是幂等的（如果你重新提交表单，你最终会得到与之相同的结果 - 例如，你没有从亚马逊那里获得两次订单。）POST意图更加自由的行为。
答案 6 :(得分：1)
如果您使用POST，则无法直接为操作添加书签。想象一下，你有一个创建新项目的方法：
？YourPage.aspx行动=创建＆安培; PARAM = ABCDE
如果我碰巧给这个make添加书签（可能是因为它显示了我要书签的另一个页面），每次打开我的书签时我都会尝试创建一个新项目。
当搜索引擎发挥作用时尤其令人担忧 - 如果你将其与错误的身份验证结合起来，那么当谷歌开始索引所有这些“动作=删除”链接时，乐趣就会开始。
也许坚持使用文字英语：使用GET获取数据，使用POST修改数据。
答案 7 :(得分：1)
正如很多人所说，它取决于您正在构建的应用程序。我遇到的几个Web应用程序的一件事是，如果你使用GET，有一个大小限制（我相信255字节）。根据您正在做的事情，这可能不是问题，但是在您将大量文本或参数传递回服务器的情况下，您可以达到此限制，这会让您疯狂地试图找出发生的事情！
答案 8 :(得分：0)
理想情况下*，POST有（或可能有迂腐）副作用，GET没有。因此，第三方可以关注GET链接而不必担心，删除内容。或者在系统中修改的任何通行证。
在某些情况下也可以安全地缓存对GET的响应，而POST永远不应该被缓存。
我不会将两者合并，只是因为你失去了这些区别。
*好的，很多人搞砸了，所以你不能依赖这种行为;但为什么要解决这个问题？
答案 9 :(得分：0)
除了已经提出的优点之外，网站浏览器，Web服务器或CGI框架中的任何一个网站都可以限制URL的长度。例如，URL通常通过具有有限大小的环境变量传递给CGI进程。如果您正在使用GET请求传递大量数据，比如编辑文本框，则可以使用该限制。通常这意味着数据被无声地截断。
答案 10 :(得分：0)
有趣的问题..在我自己的项目中直接得到POST与GET问题实际上花了我一段时间 - 但是很长一段时间我都做这样的事情：我通常在涉及表格时使用POST，并且每当我得到GET想通过常规链接触发某事。
或者这样说：我使用POST进行管理，使用GET进行导航。
考虑安全性我认为它实际上并没有太大的区别 - 攻击可以通过POST或GET进行 - 因此请务必始终检查用户的输入 - 无论您使用何种方法..
答案 11 :(得分：0)
有些调用确实应该是POST，或者提供其他方法（比如一个简单的确认问题），以确保它确实用户请求了一些操作。当允许GET改变事物时，可能容易受到cross-site request forgery（CSRF）的攻击。所以：
为了确保开发人员以安全的方式使用您的框架，可以以某种方式强制开发人员明确定义他们是否期望GET或POST。因此，您可能不想要合并参数？当不合并时，如果脚本引用POST参数，则GET可能会失败。
答案 12 :(得分：0)
我不知道它是否有任何技术基础，但对于将用于将数据写入数据库的任何变量，我总是试图让我的应用程序通过POST接收该数据。对于只搜索数据，分页表和导航等，我认为GET完全没问题。
发送欺骗性POST数据需要更多的努力和知识。可以使用地址栏操纵GET。尽管如此，如果你对进入脚本的所有用户数据采取适当的预防措施（为什么不是你！），那么数据是否通过GET或POST进入实际上并不重要。
我看到很多人在他们的应用程序中检查HTTP referrer标头，以检查POST数据是否实际来自他们的站点并且还没有被远程脚本/用户发送。但更好的方法是在表单页面上设置会话变量，并将其保存在隐藏的HTML输入中。然后在表单目标脚本上将会话变量与表单中的POSTed进行比较。这是检查POST数据来自您网站的合理方法。显然有人仍然可以加载你的表单，复制隐藏的输入值并将其发布到你的脚本，但我发现这是减少表单垃圾邮件的有效方法。