Aufruf der bit.ly REST API von Apex
Verwenden der Bit.ly V4-API über diesen Code:
HttpRequest req2 = new HttpRequest();
req2.setEndpoint('https://api-ssl.bitly.com/v4/shorten');
req2.setMethod('POST');
req2.setHeader('Authorization', 'Bearer ...');
String jsonBody = '{"long_url":"https://test.com"}';
req2.setBody(jsonBody);
req2.setHeader('Content-Type', 'application/json');
Http http2 = new Http();
HttpResponse res2 = http2.send(req2);
system.debug(res2);
ergibt die folgende Antwort:
CALLOUT_RESPONSE [24] | System.HttpResponse [Status = Not Acceptable, StatusCode = 406]
Die gleiche Anfrage funktioniert in Postman. Warum funktioniert es in Apex nicht?
Antworten
Ihr Code-Snippet
Http http2 = new Http();
HttpResponse res2 = http2.send(req2);
system.debug(res2);
sendet die Referenz ( res2) an das Debug-Protokoll. In diesem Fall ruft SF die toString()Methode für die Referenz auf und Sie sehen System.HttpResponse [Status = Not Acceptable, StatusCode = 406]als Ergebnis. toStringgibt Ihnen den Klassennamen und die Statuszeichenfolge + den zugehörigen Code. Das sind nicht genug Informationen, um zu sehen, was los ist.
Wenn Sie den Hauptteil der Antwort zusätzlich zum Status wie folgt an das Debug-Protokoll senden
system.debug(res2.getStatusCode() + ': ' + res2.getBody());
du würdest sehen
<timestamp> USER_DEBUG [12]|DEBUG|406: {"message":"INVALID_ACCEPT_HEADER"}
Dies sagt Ihnen ziemlich genau, was falsch ist - Sie müssen den AcceptHeader einfügen, um anzuzeigen, dass Ihr Client JSON als Antwort akzeptieren kann. Das funktioniert:
...
req2.setHeader('Accept', 'application/json');
Http http2 = new Http();
HttpResponse res2 = http2.send(req2);
system.debug(res2.getStatusCode() + ': ' + res2.getBody());
Abhängig von der Konfiguration kann Postman der Anforderung automatisch Header hinzufügen. Ihre Anfrage in Postman schien dieselbe zu sein wie in Apex, war es aber wirklich nicht. Beim Testen von REST-APIs ist es besser, einen Befehlszeilenclient wie z curl.