USPS API 混乱
如果有人对 USPS 递送确认 API 有任何经验,我真的很感激我能获得的任何见解...
我正在使用 PHP 和 cURL 向 DC API 发送 XML 请求。当我通过 cURL 发送响应时,我什么也没得到。没有错误响应,没有 XML,或者任何东西。当我通过浏览器发送 XML 时,我收到一个错误响应,这至少是一个响应。我处于停滞状态,因为我通过浏览器得到的错误显然(根据他们的支持热线)意味着他们的服务器问题正在影响 API。但是,我不知道为什么我无法通过 cURL 获得该响应。
If anyone has any experience with the USPS delivery confirmation API, I'd really appreciate any insight I can get...
I am using PHP and cURL to send an XML request to the D.C. API. When I send the response through cURL, I get nothing. No error response, no XML, or anything. When I send the XML through a browser, I get an error response, which is at least a response. I am at a standstill because the error I get through the browser apparantly (according to their support line) means that their server problems are affecting the API. However, I don't know why I wouldn't be able to get that response through cURL.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我们使用的是地址验证 API 和 .NET,而不是递送确认和 PHP,但也许我可以提供帮助。
您发送给邮局的 XML 应该只是查询字符串的一部分,如下所示:
然后他们会立即为您提供 XML 文档。我从未使用过 cURL 库,但也许您可以检查这是否是它实际发送的内容。
另外,你已经被批准了吗?如果没有,那么他们只允许预设的测试响应。任何其他内容都会给您带来错误,即使它在生产服务器上有效。
We're using the Address Validation API and .NET, not Delivery Confirmation and PHP, but maybe I can help.
The XML that you send the post office should just be a party of the query string like this:
Then they just serve you up an XML document right back. I've never used the cURL library, but maybe you can check that this is what it's actually sending.
Also, have you been approved yet? If not, then they only allow the canned test responses. Anything else will give you an error, even if it would be valid on the production server.
我怀疑您的请求结构中存在某些问题(例如,缺少标头),因为 XML 内容听起来像是有效的(或者至少像 USPS 的服务器正确读取它一样)。
我们的 USPS API 实现使用带有
fsockopen
的原始 TCP/IP 连接,其优点是我可以准确确认我们在请求结构中发送的内容:POST /ShippingAPI .dll HTTP/1.0
我们在请求中包含的唯一标头如下:
这与您通过 cURL 发送的内容匹配吗?
My suspicion is that something is off in the structure of your request (e.g., a missing header), since the XML content sounds like it's valid (or at least like USPS's servers read it correctly).
Our implementation of the USPS API uses a raw TCP/IP connection with
fsockopen
, which has the advantage that I can confirm precisely what we're sending in the structure of the request:POST /ShippingAPI.dll HTTP/1.0
The only headers we're including on the request are these:
Does that match what you're sending through cURL?