Die FEDEX Ship API gibt komprimierte Informationen zu bestimmten Fehlern zurück

Question

Ich habe die Fedex-API mithilfe der Check Rates-API implementiert und kann mithilfe der Ship-API Etiketten erstellen. Beide funktionierten in der Sandbox einwandfrei, also ließ ich mein Label zertifizieren und ging live. Die API sollte JSON zurückgeben. Manchmal geben API-Aufrufe mit cURL in Live- und Sandbox-Umgebungen Nicht-JSON-Antworten zurück. Mit OAuth oder Check-Rate-API-Aufrufen werden Sie nie Probleme haben, eine gute JSON-Antwort zu erhalten. Die Ship-API kann jedoch gutes JSON zurückgeben, aber auch komprimierte Antworten.

Das ist meine Curl-Anfrage.

function fedexRequest($endpoint, $post, $header = null) {
    //$ch = curl_init('https://apis-sandbox.fedex.com/' . $endpoint);
    $ch = curl_init('https://apis.fedex.com/' . $endpoint); // live
    curl_setopt_array($ch, [
        CURLOPT_SSL_VERIFYPEER => true, CURLOPT_SSL_VERIFYHOST =>
        CURLOPT_RETURNTRANSFER => true, CURLOPT_FOLLOWLOCATION =>
        CURLOPT_CONNECTTIMEOUT => 5, CURLOPT_POSTFIELDS =>
    ]);
    if ($header) curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
    return curl_exec($ch);
}

Mit diesem Code habe ich JSON und eine komprimierte Antwort erhalten. $post ist die JSON-Nutzlast, die ich ihnen sende. Spoiler Alarm! Der Fehler liegt normalerweise in den Details zu etwas in der Nutzlast. Der erste Fehler besteht darin, PackagingType = FEDEX_PAK für Artikel mit einem Gewicht von mehr als 20 Pfund festzulegen. Ein anderer Ansatz besteht darin, CM anstelle von IN für die Größeneinheiten zu verwenden.

Meine Anrufe beim Fedex Web Services-Support haben Schwierigkeiten bei der Diagnose von Nicht-JSON-Fehlerantworten. Die Antwort sieht aus wie der Code im Browser: Black Diamond vs. White? und zufällige Leerzeichen, Buchstaben und Zahlen.

Die erste Person, die mir genau erzählt, was sie beim Betrachten der API-Aufrufe meines Kontos gesehen hat, mir die Ursache und Lösung für den Fehler mitteilt und sogar meine guten Tags in Echtzeit sieht, nachdem ich ihre Einrichtung implementiert habe. Die Antworten werden bewundert. Hoffentlich bekomme ich einen direkten Rückruf von ihm. Habe heute auch ein paar Supportanrufe getätigt, aber niemand konnte die gleiche diagnostische Hilfe leisten. Der letzte besagt, dass Sie eine komprimierte Antwort erhalten, also kümmern Sie sich darum. Sie sagten, ihr Manager habe gesagt, es sei mein Code gewesen, der die komprimierte Antwort verursacht habe.

Das ist verwirrend, und während ich in der Sandbox bin, sehe ich Fehler in guten JSON-Antworten und Build-Methoden, um sie für den Endbenutzer angemessen zu analysieren. Habe auch diese Code-Antworten gesehen. Ich dachte, es wäre nur ein bekannter Fehler aus ihrer Sandbox, aber anscheinend wurden einige ihrer Fehler behoben.

Also, ich habe ein paar Fragen.

Wird die Komprimierung durch meine cURL-Anfrage verursacht?

Wenn ich CURLOPT_ENCODING in der Anfrage festlege, werden diese Antworten dann angemessener verarbeitet?

Wenn ich eine komprimierte Antwort erhalte, ist gzread oder ZipArchive die beste Möglichkeit, sie zu dekomprimieren und den tatsächlichen Fehlercode zu erhalten? Angenommen, es ist da?

Answer 1

似乎对 Fedex 的 cURL 请求可以返回压缩和未压缩的响应。将 CURLOPT_ENCODING => "" 添加到 cURL setopt 数组会自动解压缩 gzip 响应。