BitStamp API报"POST only Endpoint"错误：确认POST请求仍失败

我之前对接第三方API时也碰到过类似的“明明用了POST却提示需要POST”的诡异问题，给你几个实际可行的排查点：

• 检查请求是否被重定向修改了方法
  有些情况下，如果你的请求URL格式不对（比如末尾少了斜杠，或者用HTTP而非HTTPS），服务器可能会返回3xx重定向。部分客户端会自动跟随重定向，但把POST改成GET请求，导致最终实际发送的是GET，触发这个错误。可以查看请求的完整日志，确认有没有重定向记录，以及最终的请求方法是否还是POST。

• 核对API URL的准确性
  仔细对比你的余额API和订单API的URL，Bitstamp的不同接口可能有版本或路径差异（比如/api/v2/buy/btcusd/和/api/v2/balance/的区别）。如果路径写错，服务器可能路由到了一个只接受POST但实际你的请求被误判的端点，或者干脆是一个错误的路由返回了误导性提示。

• 确认请求头的Content-Type设置正确
  Bitstamp的私有API通常要求POST请求携带正确的Content-Type头，比如application/x-www-form-urlencoded（如果是表单参数）或者application/json（如果是JSON体）。对比下你调用余额API时的Content-Type和订单请求的是否一致，漏加或错误的Content-Type可能导致服务器无法识别POST请求的有效载荷，进而返回错误提示。

• 查看Postman的实际请求详情
  在Postman的「Console」面板里，可以看到完整的请求发送记录，包括实际使用的HTTP方法、请求头、参数等。确认这里显示的方法确实是POST，有时候Postman的自动跟随重定向设置可能会修改请求方法，或者你不小心在请求配置里选错了方法（虽然你以为选了POST）。

• 排查签名计算是否有差异
  虽然这个错误提示看起来和签名无关，但Bitstamp的交易订单API对签名的要求可能比余额API更严格——比如是否正确包含了所有请求参数、时间戳是否在有效范围内、签名算法是否正确执行。可以再核对下订单请求的签名生成逻辑，确保和余额请求的逻辑一致（除了接口特定的参数）。

内容的提问来源于stack exchange，提问作者Reath