外贸询盘表单用 GET 还是 POST：提交数据会出现在什么位置
询盘表单该用 GET 还是 POST，取决于你希望买家填写的内容出现在请求的哪个位置。GET 把信息放在请求目标之后的查询字符串里，且请求本身没有请求体；POST 把数据放在请求体中，类型由 Content-Type 指示，表单默认编码下请求体是 key=value 对。本文据此说明为什么询盘提交应落在 POST 一侧，同时划清方法语义的能力边界：POST 不等于加密、不等于防垃圾、也不等于日志里没有个人信息，这些属于传输与日志配置层面的问题，需要另行核实。文中还说明编码方式如何决定请求体的形态，以及 POST 的非幂等性对重复提交意味着什么，并给出一个明确标注为虚构的核对走查。
先看数据落在哪：查询字符串还是请求体
买家点下提交之后，他填写的公司名、联系方式与需求描述会出现在请求的哪个位置，这是选择请求方法时第一个要确定的事实。方法名称本身不回答这个问题，数据位置才回答。
按 MDN 对 GET 方法的说明，GET 请求指定资源的表示，使用 GET 的请求应只用于请求数据，不应包含请求体。 它的语法写作 http GET <request-target>["?"<query>] HTTP/1.1，其中 <query> 是可选查询组件，以问号开头，常用于以 key=value 对形式携带标识信息。 也就是说，GET 下买家填写的内容只能落在请求目标之后的查询字符串里。
POST 的位置完全不同。MDN 说明 POST 方法向服务器发送数据，请求体的类型由 Content-Type 头指示。 在方法属性上，GET 请求没有请求体、成功响应才有请求体，而 POST 请求有请求体、成功响应也有请求体。
表单默认编码下，请求体长什么样也有明确描述：使用 application/x-www-form-urlencoded 的表单，其请求体包含以 key=value 对形式、以 & 分隔的表单数据。 把这两条放在一起，读者就能回答最初的问题：GET 下数据出现在地址栏可见的查询字符串中，POST 下数据出现在请求体里，地址栏只保留请求目标。
需要说明的是，本文对读者疑问的归纳属于编辑推理，不是实测的搜索需求数据；本文也没有检查任何具体站点的表单实现，因此不对某个站点的现状下结论。
相关阅读: 外贸询盘表单产品型号字段：disabled 还是 readonly，以及提交后销售端能不能拿到型号
为什么询盘提交不该走 GET
确认了数据位置之后，下一个问题是这个位置对询盘场景是否合适。这里不需要依赖习惯说法，官方参考给出了两条可以直接引用的依据。
第一条是用途限定：GET 应只用于请求数据，不应包含请求体。 第二条针对的是把表单数据放进 GET 请求体这种做法：在 GET 请求中发送消息体的语义未定义，部分服务器可能以 4XX 客户端错误响应拒绝该请求。 这两条合起来意味着，把买家填写的内容塞进 GET 请求体既超出了该方法被定义的用途，又落在一个没有定义的行为区间里；而把内容放进查询字符串虽然符合 GET 的语法，却仍然受第一条用途限定的约束。
询盘提交在语义上属于哪一类动作，MDN 对 POST 用途的列举给出了参照：POST 被设计为以统一方法覆盖多种功能，其中包括向数据处理过程提供一块数据，例如提交表单的结果。 同一份参考还说明，HTML 表单通常使用 POST 发送数据，这通常会导致服务器端发生变化。 询盘提交正是把一块数据交给后续处理流程、并通常引起服务器端记录变化的动作，与 POST 的设计用途一致，而不是与 GET 的“只请求数据”一致。
因此对询盘表单而言，方法选择的结论是明确的：提交动作应落在 POST 一侧。这不是因为 POST 听起来更正式，而是因为 GET 的用途限定与请求体语义空白，使它不适合承载买家填写的内容。
POST 不等于加密，也不等于日志里没有个人信息
把方法改成 POST 之后，很容易顺势得出一个过头的结论：数据进了请求体，所以更安全。这个推论在官方参考里找不到依据，需要在这里划清边界。
官方参考对 POST 的说明只到这一步：POST 向服务器发送数据，请求体的类型由 Content-Type 头指示。 它没有说明请求体被加密，也没有说明服务器或中间环节不记录请求内容。 方法语义回答的是“数据放在请求的哪个位置”，它不回答“这段数据在传输和落盘过程中被如何对待”。
这两件事属于不同层面的问题。传输是否加密取决于连接层配置，日志是否记录请求内容取决于服务器与中间环节的日志配置，两者都不由方法名称决定。 同样地，POST 也不构成反垃圾手段：方法语义里没有任何关于提交来源、频率或内容可信度的判断。
本文只依据 HTTP 方法参考页讨论方法语义，没有关于传输加密、访问控制或日志处理的依据，因此这里只能指出边界，不能对任何具体站点的配置下结论。 读者需要按自身实现去核实传输与日志配置，而不是把方法选择当成安全或合规手段。
相关阅读: 外贸询盘提交成功页要不要被 Google 收录：把公开页面、私密数据与转化测量分开判断
编码方式决定请求体长什么样
确定数据放在请求体里之后，还有一个同位置上的具体决定：请求体以什么形式呈现。这由表单的编码方式决定。
默认的 application/x-www-form-urlencoded 把键和值编码为以 & 分隔、键值之间用 = 连接的键值元组；键和值中的非字母数字字符会被百分号编码。 正因为存在百分号编码，这种类型不适合二进制数据，二进制应改用 multipart/form-data。
multipart/form-data 的组织方式不同：每个值作为一块数据（body part）发送，各部分之间由用户代理定义的定界符分隔，键在各部分的 Content-Disposition 头中描述。 含文件或大量数据的表单使用这种编码，请求体用定界符字符串划分每一部分。
选哪一种不是随手决定的。MDN 说明，对 HTML 表单而言，请求体的格式与编码由 form 元素的 enctype 属性，或 input/button 元素的 formenctype 属性决定。 对询盘表单的实际含义是：如果表单里只有文本字段，默认编码就能承载；如果表单包含文件字段，编码方式需要与这一事实相匹配，否则请求体的组织方式与字段类型对不上。
相关阅读: 外贸询价表单的技术图纸上传怎么设计：类型、校验、隔离存储与业务员访问
重复提交与幂等性：同一份询盘会不会被当成两次
方法选择还会影响提交动作本身的重复语义，这一点在询盘场景里有直接的业务后果。
MDN 的方法属性说明中，POST 不是安全的、不是幂等的，只有在包含新鲜度信息时才可缓存。 同一份参考给出了具体例子：连续相同的 POST 请求可能产生额外效果，例如多次创建同一订单。
把这条落到询盘上：买家因为网络慢或页面没有反馈而重复点击提交时，服务器在语义上可能把这两次当作两次独立操作处理，而不是识别为同一份询盘。 这不是方法选择的缺陷，而是 POST 非幂等性的直接含义，它意味着去重与重复提交处理需要在实现层面单独设计。
作为对照，GET 是安全且幂等的。 但这个属性不改变前面的结论：幂等性描述的是重复请求的效果，它不能弥补 GET 在数据位置与用途限定上的不匹配。
一个假设的询盘表单走查
以下为假设的演示场景，不代表任何真实站点、客户或实测结果。假设某询盘表单声明了 method=post，字段名与取值均为虚构示例，用于说明核对动作本身。
第一项核对是数据位置：提交后确认填写内容出现在请求体中，而不是出现在地址栏的查询字符串里。 判断依据是前面已经说明的语法差异——GET 的查询组件以问号开头跟在请求目标之后，POST 的数据在请求体中。
第二项核对是编码方式：确认表单声明的编码与字段类型相匹配，纯文本字段与含文件字段对应的请求体组织方式不同。 默认编码下请求体是 key=value 对、以 & 分隔，这一点可以直接对照实际提交内容检查。
第三项核对是重复提交：确认服务器在收到两次相同提交时，是被当作两次独立操作，还是有额外的识别机制。 这一项之所以需要单独核对，是因为连续相同的 POST 请求可能产生额外效果。
走查的结论是：方法选择要跟着数据位置走，编码选择要跟着字段类型走，重复提交处理要跟着非幂等性走。这三件事各自独立，不能靠其中一项覆盖另外两项。
评论 (0)
还没有评论，来发表第一条吧。