Question

这可能看起来像一个有趣/奇怪的请求，但我想知道是否可以教导API网关响应所有请求以充当API层的引导程序/路由管理器？基本上所有要求即。 / getUser，/ getLocation，/ getManager可以写成一个API网关端点规则吗？

这里的想法是...所有GET请求无论API上的路径被路由到Lambda函数，该函数解析请求并调用正确的委托函数。

将为POST，DELETE和PUT设置类似的规则。所以基本上API网关只有4-5个注册点，所有注册点都映射到相同的Lambda函数。

我正在对网关使用的不同模式/方法进行一些早期研究，并且想知道是否可以考虑这样的事情。这有什么优点和缺点，但我只是想知道它是否可以用这种方式编写脚本。

感谢。

Answer 1

You can use request path parameters with API Gateway.

You could create several endpoints like these ones:

GET /{param1}
GET /{param1}/{param2}
GET /{param1}/{param2}/{param3}

These endpoints should match whatever url that has up to 3 path parameters. They can be configured to call the same Lambda.

In the integration request configuration, we could use something like this for the mapping template (we could add data from the body, query string and header too ...):

{
  "endpoint": {
    "path": "/$input.params('param1')/$input.params('param2')/$input.params('param3')",
    "method": "$context.httpMethod"
  }
}

Then in the lambda event, we would be able to know the HTTP method and the resource path and execute the appropriate portion of code.

An advantage would be to use more often the same lambda and improve its average performance. Indeed, if you make successive calls to a lambda, chances are that AWS re-use the same container to execute it and you don't need time to "warm it up". Using the same lambda more often should reduce the proportion of "warm up" depending on the frequency of executions.

A disadvantage is to loose the "microservice" aspect of using Lambda because all your application would be embed in only one Lambda. Another disadvantage of course is that you will have to code routing rules and execute them in the Lambda.

通过API网关引导所有入站请求

1 个答案: