好的，我一直在这些互联网上寻找对我的问题的一些见解；我可能已经经历了 80 多个堆栈溢出线程 RE api gateway 等，但它们似乎都没有帮助或与我的问题足够接近。
我是 API Gateway 和 cors 的新手，但让我们看看我是否可以阐明我所看到的问题：
为 Kinesis firehose 设置 API 网关代理，为 redshift 数据库补充水分。代理、firehose 和 redshift 网关在单独调用时启动并工作，但从我们的一个客户站点调用时，我们收到如下错误：
XMLHttpRequest cannot load [api_call_here]. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 403.
好的，这强烈暗示需要 CORS，对吧？在资源的控制台中，启用 cors，部署，新错误：
XMLHttpRequest cannot load [api_call_here]. Request header field $cookies is not allowed by Access-Control-Allow-Headers in preflight response.
Oooooooooookay，从启用 CORS 功能添加的新 OPTIONS 方法中，在集成响应中，允许的标头，在访问控制下允许的标头添加“$Cookies”，部署。
现在我收到一个新错误，与第一个错误非常相似：
XMLHttpRequest cannot load [api_call_here]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 415.
请注意，第一个错误的 HTTP 状态代码为 403，而第三个错误的状态代码为 415。这就是我遇到问题的地方。如果我进入作为代理方法的 GET 方法，身体映射模板，我选择了“当没有定义模板时（推荐）”。
现在，我读到当 API 网关找不到匹配的模板时，它会以 415 错误拒绝，所以我将上述选项更改为“当没有模板与请求 Content-Type 标头匹配时”。这使错误消失了，但是当从源调用时，数据仍然没有被持久化到红移。同样，当我直接从邮递员、失眠或只是一个普通的旧地址栏调用 api 时，记录会很好地添加。
打开 chrome 并查看标题，我看到 cookie 以 text/html 的形式出现。
关于那里的模板映射，我只为 application/json 定义了一个映射；这可能是问题的一部分吗？
此外，从 chrome 的控制台查看的响应标头如下：
content-length:37
content-type:application/json
date:Wed, 19 Apr 2017 23:43:35 GMT
status:415
via:1.1 [blahblabbleblah].cloudfront.net (CloudFront)
x-amz-cf-id:[blahblabbleblah]
x-amzn-requestid:[blahblabbleblah]
x-cache:Error from cloudfront
我对此比较陌生，所以我看不出云端如何适应这一点，尤其是考虑到它在抱怨媒体类型而控制台抱怨没有访问控制允许来源标头时。
无论如何，对于如何解决第三个错误的任何帮助将不胜感激。