“Invalid mapping expression specified” when specifying an integration response header #121
Comments
|
👍 - Getting the same issue. |
|
The error message "No method response exists for method" usually means that you don't have a method response defined matching the status code (in this case 401). Here's an example: https://github.com/awslabs/aws-apigateway-importer/blob/master/tst/resources/raml/apigateway.raml#L205 If you're still having issues send along your raml file and I'll take a look |
Yup, I get that, but I don’t think that’s what’s going on here. When I remove the |
|
Can you send a sample swagger file so that we can reproduce the issue? |
|
I can send it by email… if would that be acceptable, please shoot me a short note at avi@peggedsoftware.com and I’ll supply it. Thanks! |
|
Hi, You do need to have headers defined in your method response before they are defined in the integration response. Could that be the case here? Was the CLI command you ran was on the same resource/method or a different one that you created? I'm wondering if the error message is wrong since you're saying that removing the responseParameters field fixes the issue. Jack |
No, they’re defined properly in my RAML file.
I guess you’re referring to the case wherein I was able to successfully add this response parameter mapping manually — but in this case I used the console, not the CLI.
Seems plausible, I don’t know. |
|
@aviflax We appreciate that you are reporting this bug. |
|
@kaieongataws ah, I’m glad you figured it out! Thank you! |
|
@blakeembrey can you have a look? @kaieongataws is correct in that the method responses should be created before the integration response. I'm not sure if this is a new regression. Also I noticed that API key support is not implemented for RAML |
Seems correct to me, it's likely I wrote this out of order and didn't know that limitation - is it as easy as switching the order or is it more involved than I suspect?
There isn't a way in RAML 0.8 to specify API key support, it only describes custom scheme types using |
|
I am getting the same issue, using swagger.json file. Full file below. I even get the error if I use exact FWIW I'm using APIG-importer because its such a PITA to set response headers in the UI, so this is a blocker for me. {
"swagger": "2.0",
"info": {
"title": "MY Customer API",
"description": "Allow clients to access a subset of our APIs",
"version": "1.0.0"
},
"host": "ws.myhost.com",
"schemes": [
"https"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"security": [
{
"api_key": []
}
],
"securityDefinitions": {
"api_key": {
"type": "apiKey",
"name": "x-api-key",
"in": "header"
}
},
"paths": {
"/apps/1/get-apps": {
"get": {
"summary": "Get a list of your company’s apps",
"description": "Get a list of your company’s apps",
"tags": [
"my-apps"
],
"responses": {
"400": {
"description": "Error",
"schema": {
"$ref": "#/definitions/Error"
}
},
"500": {
"description": "Execution Error",
"schema": {
"$ref": "#/definitions/Error"
}
}
},
"security": [
{
"api_key": []
}
],
"x-amazon-apigateway-auth": {
"type": "none"
},
"x-amazon-apigateway-integration": {
"type": "http",
"uri": "https://${stageVariables.WsDomain}/apps/1/test",
"httpMethod": "GET",
"requestParameters": {
"integration.request.header.ex-1": "stageVariables.ex1",
"integration.request.header.ex2": "stageVariables.ex2"
},
"responses": {
"2\\d{2}": {
"statusCode": "200",
"responseParameters": {
"method.response.header.Cache-Control": "integration.response.header.Cache-Control"
}
},
"default": {
"statusCode": "400"
}
}
}
}
}
},
"definitions": {
"Error": {
"properties": {
"error": {
"type": "string"
},
"code": {
"type": "integer",
"format": "int32"
},
"server": {
"type": "string"
}
}
}
}
} |
|
@doapp-ryanp Same error message but different root cause. You're missing the referenced 200 response and the definition for the Cache-Control response header. You'll want to add something like this to the operation responses: |
|
@rpgreen thanks for the quick response. That did indeed fix my issue. |
|
any updates on this, was it fixed by any chance? |
|
Swagger/OpenAPI import is now generally available in the API Gateway REST API, the AWS CLI and all AWS SDKs. You can also import and export Swagger definitions using the API Gateway console. This release addresses many of the open issues and feedback in this repository. I would encourage you to migrate your workflow to the standard AWS tools. aws-apigateway-importer will receive minimal support from the API Gateway team going forward. Any feedback or issues with the new importer should be directed to the official API Gateway forums. Thanks, |
|
Thanks Ryan - this was about RAML though... |
|
Now that Swagger has been officially “blessed” by and fully integrated into API Gateway, it would seem clear that RAML is just not a high priority for the team. Next time I work on an API Gateway project I’ll probably just use Swagger, even though I prefer RAML’s semantics. |
|
Apologies - I've reopened this issue. To be clear, we still want to support RAML, it just hasn't made it into the service yet. If there is enough demand for RAML support we will certainly prioritize. |
I’m using RAML. When I specify an integration response header in my config JSON file, like so:
I get this error when running the importer:
I’ve confirmed that if I remove
responseParametersfrom the object above, the importer runs successfully with no errors.I’m confused as to what’s going on here; whether I’m doing something wrong or what… because when I specify such a response header manually in the console, it succeeds just fine. And the result of doing so manually:
as you can see, the
responseParametersproperty is identical… so I’m just confused!Any help would be greatly appreciated!
Thanks,
Avi
The text was updated successfully, but these errors were encountered: