API-Gateway: "Instanz von java.lang.String aus START_OBJECT-Token kann nicht deserialisiert werden"

Es gibt andere Fragen, die diesen Fehler abdecken, aber sie suchen nach Abfrageparametern, was nicht mein Szenario ist.API-Gateway: "Instanz von java.lang.String aus START_OBJECT-Token kann nicht deserialisiert werden"

meine einfache GET-Anfrage Testen schlägt mit dem folgend im errorMessage Feld in der Testkonsole:

Can not deserialize instance of java.lang.String out of START_OBJECT token\n at [Source: [email protected]; line: 1, column: 1

Meine Lambda-Funktion ist eine einfache Java-Klasse mit einer statischen Methode get, die einen Parameter: eine ID aus ein Pfad param.

Zum Beispiel sollte eine GET zu mysite.com/resource/1 sollte 1 zu der get Methode meiner statischen Klasse.

Ich habe kein Mapping dafür eingerichtet, weil ich den Anfragetext nicht abbilde. Die API-Gateway-Dokumentation ist sehr verwirrend und auch ziemlich leicht in ihrem Beispiel, das ein ähnliches Szenario abdeckt.

Wie kann ich einen Pfadparameter zu den Parametern meiner Lambda-Funktion zuordnen?

Quelle

2016-05-23 λlεx

Nur für Hintergrund haben die Lambda-Funktionen kein Konzept der "Parameter"; alles muss in die Anfrage Nutzlast für die Funktion gehen. In diesem Fall müssen Sie eine Mapping-Vorlage für die Integration verwenden, um die eingehenden GET-Parameter in eine JSON-Nutzlast zu transformieren, die Sie Lambda zuweisen können.

Die Pfadparameter sind im selben Mapping-Vorlagenobjekt wie die Abfragezeichenfolgenparameter verfügbar. $ Input.params ([Name]) wobei [Name] der Name des Parameters ist.

So Ihre Vorlage würde wie folgt aussehen:

Content-Type: application/json

Vorlage:

{ 
    "resourceId" : "$input.params('your_name_here')" 
}

ich die JSON-Wert in Anführungszeichen setzen, aber wenn der Wert ist garantiert Sei eine Nummer, die du entfernen kannst. Wahrscheinlich sicherer, es trotzdem in Anführungszeichen zu setzen.

Hier ist die Vorlage Referenz: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html

Die Content-Type ist tatsächlich wichtig, weil hier API-Gateway überprüft die Content-Type-Header der eingehenden Anforderung, die Zuordnungsvorlage zu bestimmen, zu verwenden. Normalerweise gibt es in GET-Anfragen keinen Content-Type-Header, daher geht API Gateway davon aus, dass Sie "application/json" verwenden möchten. Wenn Ihre Vorlage also einem anderen Inhaltstyp als application/json zugeordnet ist, funktioniert sie nicht wie erwartet.

Edit: mehr Hintergrund auf Lambda Integration

Quelle

2016-05-31 17:19:11

Ist '$ input.params' Abdeckung Pfadparameter auch? Ich habe das versucht und immer noch das gleiche Problem. –

Ja, tut es. Es ist möglich, dass der Parameter nicht korrekt eingerichtet ist? Also ist der Ressourcenpfad "/ resource/{foo}" und dann ist ein Pfadparameter namens 'foo' korrekt? In diesem Fall sollte die Vorlage, die ich oben eingefügt habe, perfekt funktionieren, wenn Sie verwenden "ressourceId": "$ input.params ('foo')" } –

Der Inhaltstyp verwirrt mich hier, denn wie Sie sagen, es ist ein GET Anfrage.Die Antwort ist im Moment nur ein String und die Handler-Methode in Java ist einfach 'public static String get (String id) {...}'. Die GET-Anfrage an meine bereitgestellte Version sollte nur 'get (pathParameter)' aufrufen, aber anscheinend bekomme ich dieselbe Fehlermeldung. Außerdem habe ich den Inhaltstyp auf application/json gesetzt, wie Sie ihn vorschlagen und zuordnen, und erhalte trotzdem den Fehler. Verblüffung. –

API-Gateway: "Instanz von java.lang.String aus START_OBJECT-Token kann nicht deserialisiert werden"

Antwort

Verwandte Themen