2016-04-07 8 views
2

Wir entwickeln eine Meteor-App, die intern erstellte RESTful-API aufruft. Unser Server erwartet, dass der Header "Content-type: application/json" gesetzt ist und er antwortet immer mit dem gleichen Header (Content-Type: application/json; charset=UTF-8) und einem JSON-formatierten Body, unabhängig vom Statuscode.Analysieren fehlerhafter Serverantworten in Meteor

paar Beispiele:

# SERVER RESPONDED WITH 200: 
HTTP/1.1 200 OK 
Content-Length: 338 
Content-Type: application/json; charset=UTF-8 
Date: Thu, 07 Apr 2016 10:44:33 GMT 
Server: nginx 

{ 
    "result": "Hello, world!", 
    "status": "OK" 
} 


# RESPONSE WITH SOME ERRORS: 
HTTP/1.1 400 Bad Request 
Content-Length: 547 
Content-Type: application/json; charset=UTF-8 
Date: Thu, 07 Apr 2016 10:23:49 GMT 
Server: nginx 

{ 
    "errors": [ 
     { 
      "description": "error desc.", 
      "location": "error location", 
      "name": "error name" 
     } 
    ], 
    "status": "error" 
} 

In Meteor, verwenden wir eine Methode, wie diese API aufrufen:

let url = 'https://server.url/path'; 
var auth = "user:pass"; 
var headers = {"Content-type": "application/json"}; 

let objId = 100; 
let report_type = 'some_type'; 
let data = { 
    object_id: objId, 
    report_type: report_type 
}; 
let payload = {auth, headers, data}; 
try { 
    var result = HTTP.post(url, payload); 
} catch (exc) { 
    console.log(exc); 
    return exc; 
} 
return result; 

Das Problem hier ist, wenn Server mit 4xx/5xx Fehler reagiert, die exc Objekt ist kein richtiges JSON-formatiertes Objekt (wir versuchen dies mit Meteor 1.2 und 1.3), aber es sieht so aus:

{ [Error: failed [400] {"errors": [{"description": "error desc.", "location": "error location", "name": error name"}], "status": "error"}] stack: [Getter] } 

Bei einer Antwort von 200 ist das result ein richtiges JSON-Objekt und wir können es ohne Probleme analysieren.

Wir versuchten, unseren Server-Aufruf zu Meteor Async-Aufruf zu ändern, und in diesem Fall funktioniert alles einwandfrei - wir können Fehler headers und zugreifen und es richtig analysieren.

Meine Frage ist: Warum ist die Antwort um { [Error: failed [400] {"original_response": "here"}] stack: [Getter] } gewickelt und wie in diesem Fall den Fehler richtig analysieren? Fehlt uns irgendwo ein Header (Server oder Meteor App), damit Meteor das Objekt exc richtig konstruiert, wenn es eine falsche Antwort bekommt?

+0

Meteor wirft einen Fehler, wenn es eine ist 4xx/5xx Antwort, Ihre Serverantwort befindet sich innerhalb des Fehlers, Sie könnten die Fehlerzeichenfolge analysieren und die JSON-Daten abrufen. Überprüfen Sie die Dokumentation, es scheint, dass die Verwendung eines Async-Callback nicht den Fehler wirft, dann können Sie vielleicht das Ergebnis erhalten: http://docs.meteor.com/#/full/http – ojovirtual

+0

Ah ja, ich habe vergessen, das zu erwähnen wir haben versucht, einen asynchronen Anruf zu verwenden, ich werde meinen Beitrag mit diesen Informationen aktualisieren :) – errata

Antwort

1

Nun, offenbar Meteor v1.3 ist die Ausnahme in einer anderen Art und Weise wickelt, so in meinem Fall kann das Objekt in der Ausnahme mit exc.response jetzt zugegriffen werden ...