顾 静

顾 静

1660047240

带有 .NET 的 Amazon API 网关

在这篇综合文章中,我们将学习使用 .NET 堆栈的 Amazon API Gateway。使用它,我们将能够很容易地将 AWS Lambdas 暴露给外部世界。

在之前的文章中,我们了解了如何使用 .NET 使用 AWS Lambda,这是开始使用无服务器应用程序的关键点。尽管我们在 AWS 上构建并部署了这些 Lambda,但我们从未真正讨论过如何将它们公开以供外部世界调用。

在本综合指南的进一步内容中,我们将构建一个完整的无服务器应用程序,该应用程序在 Amazon API Gateway、Lambda、DynamoDb for Persistence 和 Cloudwatch 之间无缝集成以用于日志记录。

您可以在此处找到实现的源代码

什么是亚马逊 API 网关?

Amazon API Gateway 是一项完全托管的服务,可让您创建网关,它本质上是进入应用程序业务逻辑世界的大门。使用此服务,您基本上可以公开访问连接到 AWS Lambda、公共终端节点和各种其他 AWS 服务的终端节点,具体取决于您构建 Amazon API Gateway 的方式。

假设某些在 Internet 上运行的应用程序需要访问您的 lambda 中的业务逻辑。这些客户端应用程序将连接到 Amazon API Gateway,后者会在内部将请求重定向到关联的 AWS Lambda 或您将配置的其他服务。

让我们看一下通过 API 网关的常见请求流的图示。

带有 .NET 的 Amazon API 网关

如您所见,客户端访问内部连接到服务的网关。例如,

  • www.<url-of-aws-gateway>/test -> 将重定向到名为 test-lambda 的 lambda
  • www.<url-of-aws-gateway>/get-students -> 将重定向到返回学生列表的 lambda
  • www.<url-of-aws-gateway>/weather?city=trivandrum -> 将重定向到公共天气 API 端点,该端点将返回特里凡得琅市的天气数据。

现在,API 网关通常是整个 AWS 无服务器生态系统的重要组成部分,因为它让以任何规模访问我们的 AWS 服务变得非常酷且容易。

AWS REST API 与 HTTP API

AWS 支持两个版本的 API 网关服务。最初的版本是针对 REST API 变体,其中包含大量用于设计、开发和维护 API 网关的功能。后来,在 2019 年左右,AWS 引入了 HTTP API,简化了网关的创建和部署。不要与命名混淆,这两个版本都是基于 REST 约定的 HTTP 协议构建的。AWS 在内部将它们命名为 v1(REST API)和 v2(HTTP API)

这些版本之间存在很多显着差异,包括性能、定价和开发体验。简而言之,HTTP API 在几乎所有部门中都胜出,大多数时候应该是您的选择。

  • 首先,HTTP API 旨在提高性能,与 REST API 相比,性能几乎提高了 10-15%。
  • 在定价方面,对于每月前 3 亿个请求,HTTP API 的成本仅为 1 美元,而对于相同的数量,REST API 的成本约为 3.5 美元。这是一个巨大的差异。请注意,AWS 免费套餐包括前 12 个月每月 100 万个 API(REST 和 HTTP),完全免费。有足够的时间来探索这两种很酷的技术,对吧?
  • AWS 控制台在开发这些网关时提供的用户体验完全不同。
  • REST API 支持边缘优化端点,可确保您的端点在全球范围内高度分布,而 HTTP 端点仅支持区域部署,这可能会导致响应稍有延迟。
  • 这两者本质上都是高度安全的。
  • 如果这对您的部署策略来说意义重大,则金丝雀部署包含在 REST API 中,而不包含在 HTTP API 中。

如需更多比较,请参阅比较这两个版本的AWS 开发人员指南。尽管 HTTP API 比 REST 便宜,但 REST API 中肯定包含很多功能,这证明了价格差异是合理的。

至于我们的演示,我们将使用 HTTP API。也许在以后的文章中,我们将探讨 REST API。从概念上讲,这两者几乎相同。我们将使用 Visual Studio 2022 Community 和 AWS SDK Kit 扩展,就像我们在上一篇关于 Lambda 的文章中所做的那样来开发、测试、模拟并将我们的 Lambda 发布到 AWS 云。

重要的是,您已经阅读了上一篇关于 .NET 上的 AWS Lambda 的文章,其中我们通过 CLI 设置了 AWS 凭证,在 Visual Studio Code 上安装了 AWS Toolkit。如果没有,请参考这篇博文。

使用 .NET 构建和发布 AWS Lambda

首先,让我们打开 Visual Studio 2022 并创建一个空白解决方案。我将我的解决方案命名为AWSServerless.Dotnet.Demo。基本上,我们将有 2 个 Lambda 项目,我们将逐步添加。

  1. 一个返回 Hello 消息的虚拟 Lambda。此 lambda 将用于介绍 Amazon API Gateway 集成基础知识和内容。
  2. 一个学生 Lambda,我们将向其中添加多个函数处理程序,这些处理程序可能对 DynamoDB 执行一些基本的 CRUD 操作。(PS,我写了一篇关于使用 .NET 开始使用 DynamoDB 的文章。请检查一下。)

在继续之前,请确保您已准备好以下各项。

  • 通过 AWS CLI 设置 AWS 凭证。
  • AWS Toolkit 安装在您的 Visual Studio 安装中。
  • 拥有 AWS 账户。免费套餐绰绰有余。

您可以在我之前关于使用 .NET 的 AWS 无服务器应用程序的文章中获得与上述步骤相关的更多信息。

使用 .NET 创建空白项目 aws 无服务器 Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

让我们将我们的第一个 Lambda 项目添加到我们的空白解决方案中。右键单击 Visual Studio 中的解决方案,然后单击添加新项目。假设您已经在 Visual Studio 实例上安装了 AWS Toolkit,您可以在出现的“添加新项目”弹出窗口中搜索 AWS Lambda。

devenv iArkd7DjVv Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

单击下一步。在这里,我们将 lambda 命名为 HelloLambda。如前所述,这将是一个简单的 lambda,它可以帮助我们了解与 .NET 与 Amazon API Gateway 的整个集成是什么样的。当系统提示您为新的 lambda 选择蓝图时,选择“Empty Function”。这为我们提供了一个全新的开始构建我们简单的 Lambda。

您应该已经熟悉 AWS Lambda 项目的文件夹结构。如果没有,请阅读本文。打开 Function.cs / FunctionHandler。现在我们要将这个 Handler 附加到我们的 API 网关中,我们需要对这个方法的签名进行一些微小的修改。但在此之前,让我们为这个包含合约的 Lambda 项目安装一个包。您可以打开包管理器控制台并运行以下命令来安装包。

Install-Package Amazon.Lambda.APIGatewayEvents

现在让我们去改变我们的 FunctionHandler。

public APIGatewayHttpApiV2ProxyResponse FunctionHandler(APIGatewayHttpApiV2ProxyRequest request, ILambdaContext context)
{
request.QueryStringParameters.TryGetValue("name", out var name);
name = name ?? "John Doe";
var message = $"Hello {name}, from AWS Lambda";
return new APIGatewayHttpApiV2ProxyResponse
{
Body = message,
StatusCode = 200
};
}

APIGatewayHttpApiV2ProxyRequest 表示来自 HTTP API 的传入请求。如果您考虑一下,或者如果您回顾我们的第一个流程图,Lambda 收到的请求并不是直接来自客户端,而是来自 Amazon API Gateway 本身的请求。因此,在这种情况下,API 网关使用APIGatewayHttpApiV2ProxyRequest类型向 Lambda 发送请求。同样,APIGatewayHttpApiV2ProxyResponse是 Lambda 返回给 Amazon API Gateway 的响应类型。您也可以跳过此响应部分,而是返回一些关键数据作为业务需求,例如学生列表,我们将在本指南中进一步构建下一个 Lambda 时执行此操作。

所以这些是 Lambda 中支持整个 API 网关集成的主要变化。除此之外,函数处理程序现在返回一条消息,指出“Hello {name},来自 AWS Lambda”。这里的另一件事是,在 Lambda 中,您可以访问传入的上下文,其中包括查询字符串、路径参数、路由等。对于这个 Lambda,我希望传入的请求会有一个名称为 (.../hello?name=Mukesh) 的查询参数,然后将其添加到它最终返回的消息中。

如果查询参数不存在,它会使用默认名称,即 John Doe。请注意,我们以APIGatewayHttpApiV2ProxyResponse 类型返回响应,其中 Body 是实际消息,我们提供状态代码 200 SUCCESS。

这就是我们的第一个 Lambda。让我们将它发布到 AWS 并在 Visual Studio 中本地模拟测试它。右键单击 HelloLambda 项目,然后单击 Publish to AWS Lambda。您将看到以下弹出窗口。

image 带有 .NET 的 Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

假设您已设置本地 AWS 凭证、区域和配置文件,该工具会自动填写前几个详细信息。

  • 函数名称是在您的 AWS 账户中识别 Lambda 的名称。
  • 描述——顾名思义。
  • 处理程序在这里有点重要。假设您的 Function.cs 可能有多个 Handler 方法。此 Handler 方法映射到您需要 Lambda 指向的确切函数。在我们的例子中,它是 HelloLambda::HelloLambda.Function::FunctionHandler。请记住这一点,因为我们将在本文后面使用此字段。

点击下一步。

devenv oEzQI2HY6h Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

在下一个屏幕中,您需要做的唯一更改是选择所需的正确角色。在我们的例子中,它是 AWSLambdaBasicExecutionRole。这带有将日志写入 AWS Cloudwatch 的权限。而已。单击上传。AWS 开始创建所需的角色,运行一些命令以在本地构建和发布您的 Lambda,压缩已发布的库,并将其上传到 AWS,最终创建您的新闪亮 Lambda。

带有 .NET 的 Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

完成后,您可以打开 AWS 管理控制台,导航到 Lambda 并验证我们的新 Lambda 是否已创建。

图 2 带有 .NET 的 Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

回到 Visual Studio,您可以看到发布向导会打开一个小工具,帮助直接从 Visual Studio 测试我们的 Lambda。哦,如果你还不知道,你也可以简单地在调试模式下运行 Lambda 应用程序,Visual Studio 会启动一个 Mock Tool,它基本上可以帮助测试和调试你的 Lambda 代码。

现在,让我们探索 Visual Studio 界面中内置的工具。这是下面的屏幕截图。

图 1 带有 .NET 的 Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

首先,此接口允许您将模拟请求直接发送到已部署到 AWS 的 Lambda。单击示例请求下拉菜单,然后选择 API Gateway AWS 代理。该工具将填写一个示例请求。在这里,和我一样,您可以向查询字符串参数添加名称键/值。这里有很多房产可以摆弄。单击 Invoke 后,响应中将包含我们的消息,状态代码为 200。

现在,虽然 Lambda 已经准备就绪,但除了 VS 调试工具之外,我们真的没有其他方法可以访问此函数。因此,我们需要一个向其发送请求的链接/端点,并且我们期望来自 Lambda 的类似请求返回。这就是 Amazon API Gateway 发挥作用的地方。

使用 .NET 创建 Amazon API 网关

让我们开始设计我们的第一个 Amazon API 网关。在您在 AWS 管理控制台中看到的搜索栏中搜索 API Gateway。您将看到 Amazon API Gateway 的默认登录页面。在这里,您将看到选择 API 类型的选项。由于我们将使用 HTTP API,让我们点击与之关联的 Build 按钮。

chrome HZudzLTStT Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

鉴于我们的 Lambda 已成功创建,您可以选择集成类型为 Lambda 并选择我们的 hello Lambda 函数。确保我们坚持使用有效载荷的 2.0 版,因为它是最新的。此外,请确保选择正确的 AWS 区域。就我而言,它是 ap-south-1。完成后,单击下一步。

带有 .NET 的 chrome ZaswQgDPsT Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

接下来是一个有趣的部分,我们在其中配置可以调用我们的 hello Lambda 的实际路由。您可以看到我已将其设为 GET 方法,该方法的端点为 /hello 并以 Hello Lambda 为目标。所以基本上,一旦我们创建了 API 网关,AWS 就会为我们提供一个端点 URL,如果我们添加一个 /hello 并发送一个带有适当查询参数的 GET 方法将触发 Lambda 并返回预期的响应。

请注意,您可以在此处使用多个路由和集成。我们将在本文后面创建完整的 API 网关时对此进行探讨。

chrome 1j5EYx3xWe Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

接下来,向导将要求我们创建阶段。如果我们想将我们的 Amazon API Gateway 部署到不同的阶段,如开发、生产和登台,这将非常方便。但是现在,让我们将其保留为默认值“$default”,然后单击“下一步”。

您可以在此处查看您的更改并部署您的网关。就是这样,就这么简单。

在下面的屏幕中,您可以看到我们刚刚创建的 Amazon API Gateway 的 URL。复制它并打开 Postman 或您使用的任何 API 测试工具。此外,由于它只是一个 GET 方法,您甚至可以自由地使用浏览器来测试我们的网关。

带有 .NET 的 chrome kmkvkIZHmM Amazon API 网关 - AWS Lambda 和 DynamoDB 集成

让我们测试一下我们的 API 网关将如何响应。我将使用 Postman 进行测试。确保它是一个 GET 方法,否则网关会喊出找不到这样的端点。

在下面的屏幕截图中,您可以看到我向 /hello 端点发送了一个请求,并将查询参数名称作为我的 Name 传递,您还可以看到 Lambda 的预期响应。很简单,对吧?随意摆弄 Hello Lambda 以了解更多信息。

Postman 09XFb6JnKd Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

探索 Amazon API Gateway 控制台界面

现在我们已经创建了第一个使用 .NET 支持的 AWS Lambdas 的 Amazon API Gateway,让我们探索一下 Amazon API Gateway 上提供的接口和功能。

在主页上,您可以看到您在特定 AWS 区域中创建的网关列表。

带有 .NET 的 chrome RYg52eeVpW Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

一旦您进入特定的 API 网关,您就可以访问一系列很酷的功能来调整您的网关。

chrome C3lh3VJBk3 Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

从这里,您可以:

  • 向现有 Amazon API Gateway 添加更多路由。
  • 使用 Lambda 和 JWT 保护 Amazon API Gateway。我们将在下一篇文章中深入探讨!
  • 管理集成和 Lambda。
  • 配置 CORS 策略。
  • 导出/导入 OpenAPI 定义。
  • 如果需要,写入访问日志。因此,每次通过 API 网关发送请求时,该请求都会记录到 Cloudwatch。您必须为此指定一个日志组目标。我们将在本文后面对此进行研究。
  • 管理/创建阶段等等。

现在我们已经基本了解了 Amazon API Gateway 与 .NET 的工作原理,现在让我们构建一个更高级的无服务器应用程序,该应用程序利用 AWS Lambda、多个函数处理程序、Cloudwatch、DynamoDB 存储数据,最后集成所有这些 Lambda 使用 Amazon API 网关。

使用 .NET 构建学生管理 AWS Lambda

我们将构建一个简单的 API,它可以获取所有学生详细信息、通过 ID 获取学生并创建新的学生记录。将一个新的 Lambda 项目添加到我们的解决方案并将其命名为 StudentLambda。是的,我们将从一个 Lambda 项目创建多个 Lambda。您可以自由地为每个功能创建单独的项目。但就目前的应用范围和需求而言,确实没有必要。我们将所有 3 个 Lambda 函数填充到一个 .NET Lambda 项目中,并利用 FunctionHandlers 将所有 Lambda 单独部署到 AWS。

在开始之前,请确保通过包管理器控制台将以下 Nuget 包安装到您的 StudentLambda 项目。

Install-Package Amazon.Lambda.APIGatewayEvents
Install-Package AWSSDK.DynamoDBv2
Install-Package Newtonsoft.Json

如您所知,第一个包专门用于在我们的 .NET Lambda 中使用 Amazon API Gateway 合约。

DynamoDB 包让我们的 Lambda 与我们的 DynamoDB 进行通信。如果您不了解 DynamoDB 的工作原理,我已在此处编写了一份完整的指南。我构建了一个简单的 CRUD ASP.NET Core WebAPI,它将数据存储到 AWS DynamoDB 表中。

接下来,让我们定义学生模型。使用 StudentLambda 项目的根目录,添加一个新类并将其命名为 Student.cs

namespace StudentLambda
{
[DynamoDBTable("students")]
public class Student
{
[DynamoDBHashKey("id")]
public int? Id { get; set; }
[DynamoDBProperty("first_name")]
public string? FirstName { get; set; }
[DynamoDBProperty("last_name")]
public string? LastName { get; set; }
[DynamoDBProperty("class")]
public int Class { get; set; }
}
}

现在导航到 AWS DynamoDB 并在那里创建一个新表,如下所示。

chrome FCz71W3ljT Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

创建表后,AWS 将花费几秒钟时间将表预置到云中。让我们在这个表中添加一个示例记录。打开表格,点击探索表格项目-> 创建项目。

切换到 JSON 视图并添加如下示例记录。请注意,我使用的属性与我们在 Student.cs 类中定义的属性完全相同。单击创建。

{
"id": 1,
"first_name" : "Mukesh",
"last_name" : "Murugan",
"class" : 10
}

带有 .NET 的 chrome MotUEECHAR1 Amazon API 网关 - AWS Lambda 和 DynamoDB 集成

让所有学生

让我们编写一些代码以从 DynamoDB 表中返回所有学生的列表。打开 StudentLambda 的 Function.cs 类。删除默认的 FunctionHandler 方法。并添加以下功能。

public async Task<List<Student>> GetAllStudentsAsync(APIGatewayHttpApiV2ProxyRequest request, ILambdaContext context)
{
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
DynamoDBContext dbContext = new DynamoDBContext(client);
var data = await dbContext.ScanAsync<Student>(default).GetRemainingAsync();
return data;
}

所以这个函数本质上是扫描整个 DynamoDB 表的名字学生并返回一个学生列表。就如此容易。请注意,我们将创建几个 DynamoDB 客户端和上下文来从 AWS Lambda 访问我们的数据。

一旦所有 3 个完成,我们将部署这些 Lambda。理想情况下,此 Lambda 的端点将是 <amazon-url>/students [GET] 方法。

创建学生

接下来,在 Student Lambda 的 Same Function.cs 中,让我们添加另一个负责创建新学生记录的方法。下面是函数。

public async Task<APIGatewayHttpApiV2ProxyResponse> CreateStudentAsync(APIGatewayHttpApiV2ProxyRequest request, ILambdaContext context)
{
var studentRequest = JsonConvert.DeserializeObject<Student>(request.Body);
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
DynamoDBContext dbContext = new DynamoDBContext(client);
await dbContext.SaveAsync(studentRequest);
var message = $"Student with Id {studentRequest?.Id} Created";
LambdaLogger.Log(message);
return new APIGatewayHttpApiV2ProxyResponse
{
Body = message,
StatusCode = 200
};
}

因此,在这里我们希望客户端发送一个包含学生详细信息的 JSON 正文。

第 3 行,我们将传入的请求正文反序列化为 Student 对象。然后我们创建一个用于访问 dynamoDb 表的数据库上下文,并将学生记录保存到我们的数据库中。完成后,我们将向客户端返回一条成功消息作为状态码为 200 的响应。

在第 8 行,您可以注意到我们正在使用 LambdaLogger 实例将消息记录到 Lambda 的 Cloudwatch LogGroup。理想情况下,此端点将是 <amazon-url>/students [POST] 方法。

通过 ID 获取学生

继续我们的 Last lambda 函数,让我们添加一个函数,该函数可以根据请求中发送的 ID 返回学生。这将是一个稍微不同的函数,因为我们必须从请求的路径参数中获取 ID。例如,这个部署端点看起来像 <amazon-url>/students/{id}。

Copy 将以下方法粘贴到 Student Lambda 项目的 Function.cs。

public async Task<Student> GetStudentByIdAsync(APIGatewayHttpApiV2ProxyRequest request, ILambdaContext context)
{
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
DynamoDBContext dbContext = new DynamoDBContext(client);
string idFromPath = request.PathParameters["id"];
int id = Int32.Parse(idFromPath);
var student = await dbContext.LoadAsync<Student>(id);
if (student == null) throw new Exception("Not Found!");
return student;
}

在第 5 行中,我们从请求的路径参数属性中提取学生 ID。获取它后,我们将其转换为整数并将其传递给 dynamoDb 方法以通过 Id 获取学生。该学生记录作为响应返回给客户端。

现在,所有的 lamda 函数都创建好了。让我们将它们部署到 AWS。

在 Visual Studio 上,右键单击 StudentLambda 项目,然后单击发布到 AWS Lambda。我们将依次部署这 3 个功能中的每一个。

在下面的屏幕上有 2 点需要注意。函数名称为“get-all-students”,处理程序指向 GetAllStudentsAsync 方法。这就是我们分别发布所有 3 个 Lambda 的方式。你现在一定已经明白了。更改这些字段后,单击下一步。

devenv lP4870ufPw Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

在下一个屏幕中,您需要选择与此 Lambda 关联的角色。对于初学者,它可以是 AWSLambdaBasicExecution 角色。但是,这有一个问题。此特定角色仅提供执行 Lambda 并将日志写入 Cloudwatch 的访问权限。但是没有权限访问我们的 DynamoDB 表,对吧?我们将在部署所有 Lambda 后解决此问题。

devenv k3q9el3o6D Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

就是这样,上传 get-all-students Lambda。

重复类似的步骤来部署剩余的 Lambda。确保为这 2 个 AWS Lambda 中的每一个选择已创建的角色。

devenv 12JZFkHk21 Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

devenv fycfsY0BNP Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

devenv jD6jBn30hv Amazon API Gateway with .NET - AWS Lambda & DynamoDB 集成

而已!这是我们到目前为止创建的 Lambda。

chrome yqXn6ON0rX Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

添加 DynamoDB 权限。

如前所述,让我们将所需的 DynamoDB 权限添加到我们创建的角色中。导航到 AWS IAM。转到策略并使用以下规范创建一个。正如您在此处看到的,我们已选择 DynamoDB 作为 AWS 服务并允许所有 DynamoDB 操作以及所有资源。

chrome Ql3GcGoy6E Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

请注意,向特定角色授予完整权限并不总是一个好主意。但是为了简单起见,我们正在这样做。您不应该为生产应用程序执行此操作。仅授予真正需要的权限。

在下一页上,为策略命名并创建它。

chrome ycODtFF4xn Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

现在我们已经创建了策略,让我们将它附加到我们的角色。从列表中选择新创建的策略,然后单击附加。在下一页上,您必须选择要将此策略附加到的角色/用户/组。

chrome BXL706oAoM Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

在我们的例子中,它是 lambda_exec_get-all-students

带有 .NET 的 chrome mAu7ftXH2A Amazon API 网关 - AWS Lambda 和 DynamoDB 集成

你去吧。我们已成功地将策略​​附加到我们的 AWS Lambda 使用的角色。现在 Lambda 应该有足够的权限来使用 DynamoDb。

使用 .NET AWS Lambda 连接 Amazon API Gateway

接下来是指南的关键部分,实际构建一个触发每个 lambdas 的 API 网关。从 AWS 管理控制台打开 Amazon API Gateway。

到目前为止,我们只创建了一个 API Gateway,它是hello。创建一个新的 API 网关。像往常一样,选择 HTTP API 类型并点击 Build。

我们将网关命名为学生,并将所有 3 个 Lambda 都添加为集成。很简单,对吧?

带有 .NET 的 chrome j6Rwc9eHTU Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

在下一页中,我们将配置我们的路线。我们将更改默认值并添加以下配置。

chrome HTdaHTJd1a Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

  • GET /students 将调用 get-all-students
  • GET /students/{id} 将调用 get-student-by-id ,其中 id 是请求的路径参数。例如,/学生/1
  • 最后,POST /students 将创建一个新学生,因为我们已将新学生的详细信息作为请求的 JSON 有效负载传递。
     

将阶段保留为默认值并继续创建网关。

带有 .NET 的 chrome b5Pqmem97h Amazon API Gateway - AWS Lambda 和 DynamoDB 集成

给你,就是这样。让我们用 Postman 测试这个端点。

首先,我正在测试 get-al-students Lambda。我向 <url>/students 发送了一个 GET 请求。正如预期的那样,您会看到一个学生列表作为响应。目前,我们的数据库中只有一条记录。

Postman IEQHc2RddV Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

接下来,让我们测试 get-student-by-id Lambda。我向 <url>/students/1 发送了一个 GET 请求。它正确地返回了 ID 为 1 的学生的详细信息。

Postman Z6R9hqnoka Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

最后,让我们创建一个新学生。向 <url>/students 端点发送 POST 请求以及学生详细信息。响应是我们的学生是用 ID 2 创建的!

Postman 7lDzMoDjEr Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

另外,还记得我们在 Create-Student Lambda 中编写了一个小型 Logger 吗?让我们导航到 Cloudwatch / Log Groups / create-student 并检查日志。

chrome kBWX1ReSVr Amazon API Gateway with .NET - AWS Lambda 和 DynamoDB 集成

您可以看到我们的日志消息也打印在这里。

这是这篇综合文章的总结。在下一篇文章中,我们将学习如何使用 Lambda Authorizer 保护 API 网关!目前,我们创建的 API 网关是一个公共端点。

重要提示:确保在完成探索后始终删除您创建的 AWS 资源。这有助于减少产生的成本,尽管免费层为您提供了相当数量的免费请求。

概括

在本文中,我们了解了如何使用 .NET 开始使用 Amazon API Gateway。在这里,我们了解了如何创建与 Amazon API Gateway 兼容的基本 Lambda、将它们集成到 DynamoDB、将多个 Lambda 添加到特定网关、日志记录等等。这将为您提供使用 AWS 无服务器应用程序的可靠思路。作为这个带有 .NET 的 AWS 无服务器应用程序的下一部分,我们将探索如何保护 API 网关,以及如何使用 SAM 等等。敬请关注。当我发布新文章时,您可以关注此时事通讯以获取通知 – https://www.getrevue.co/profile/iammukeshm

如果您觉得这篇文章很有趣,请与您的同事和开发人员圈子分享这篇文章。你可以在这里找到 项目的源代码 。谢谢!  

 来源:https ://codewithmukesh.com/blog/amazon-api-gateway-with-dotnet/

#dotnet #amazon #api 

What is GEEK

Buddha Community

带有 .NET 的 Amazon API 网关
Einar  Hintz

Einar Hintz

1602560783

jQuery Ajax CRUD in ASP.NET Core MVC with Modal Popup

In this article, we’ll discuss how to use jQuery Ajax for ASP.NET Core MVC CRUD Operations using Bootstrap Modal. With jQuery Ajax, we can make HTTP request to controller action methods without reloading the entire page, like a single page application.

To demonstrate CRUD operations – insert, update, delete and retrieve, the project will be dealing with details of a normal bank transaction. GitHub repository for this demo project : https://bit.ly/33KTJAu.

Sub-topics discussed :

  • Form design for insert and update operation.
  • Display forms in modal popup dialog.
  • Form post using jQuery Ajax.
  • Implement MVC CRUD operations with jQuery Ajax.
  • Loading spinner in .NET Core MVC.
  • Prevent direct access to MVC action method.

Create ASP.NET Core MVC Project

In Visual Studio 2019, Go to File > New > Project (Ctrl + Shift + N).

From new project window, Select Asp.Net Core Web Application_._

Image showing how to create ASP.NET Core Web API project in Visual Studio.

Once you provide the project name and location. Select Web Application(Model-View-Controller) and uncheck HTTPS Configuration. Above steps will create a brand new ASP.NET Core MVC project.

Showing project template selection for .NET Core MVC.

Setup a Database

Let’s create a database for this application using Entity Framework Core. For that we’ve to install corresponding NuGet Packages. Right click on project from solution explorer, select Manage NuGet Packages_,_ From browse tab, install following 3 packages.

Showing list of NuGet Packages for Entity Framework Core

Now let’s define DB model class file – /Models/TransactionModel.cs.

public class TransactionModel
{
    [Key]
    public int TransactionId { get; set; }

    [Column(TypeName ="nvarchar(12)")]
    [DisplayName("Account Number")]
    [Required(ErrorMessage ="This Field is required.")]
    [MaxLength(12,ErrorMessage ="Maximum 12 characters only")]
    public string AccountNumber { get; set; }

    [Column(TypeName ="nvarchar(100)")]
    [DisplayName("Beneficiary Name")]
    [Required(ErrorMessage = "This Field is required.")]
    public string BeneficiaryName { get; set; }

    [Column(TypeName ="nvarchar(100)")]
    [DisplayName("Bank Name")]
    [Required(ErrorMessage = "This Field is required.")]
    public string BankName { get; set; }

    [Column(TypeName ="nvarchar(11)")]
    [DisplayName("SWIFT Code")]
    [Required(ErrorMessage = "This Field is required.")]
    [MaxLength(11)]
    public string SWIFTCode { get; set; }

    [DisplayName("Amount")]
    [Required(ErrorMessage = "This Field is required.")]
    public int Amount { get; set; }

    [DisplayFormat(DataFormatString = "{0:MM/dd/yyyy}")]
    public DateTime Date { get; set; }
}

C#Copy

Here we’ve defined model properties for the transaction with proper validation. Now let’s define  DbContextclass for EF Core.

#asp.net core article #asp.net core #add loading spinner in asp.net core #asp.net core crud without reloading #asp.net core jquery ajax form #asp.net core modal dialog #asp.net core mvc crud using jquery ajax #asp.net core mvc with jquery and ajax #asp.net core popup window #bootstrap modal popup in asp.net core mvc. bootstrap modal popup in asp.net core #delete and viewall in asp.net core #jquery ajax - insert #jquery ajax form post #modal popup dialog in asp.net core #no direct access action method #update #validation in modal popup

Top 10 API Security Threats Every API Team Should Know

As more and more data is exposed via APIs either as API-first companies or for the explosion of single page apps/JAMStack, API security can no longer be an afterthought. The hard part about APIs is that it provides direct access to large amounts of data while bypassing browser precautions. Instead of worrying about SQL injection and XSS issues, you should be concerned about the bad actor who was able to paginate through all your customer records and their data.

Typical prevention mechanisms like Captchas and browser fingerprinting won’t work since APIs by design need to handle a very large number of API accesses even by a single customer. So where do you start? The first thing is to put yourself in the shoes of a hacker and then instrument your APIs to detect and block common attacks along with unknown unknowns for zero-day exploits. Some of these are on the OWASP Security API list, but not all.

Insecure pagination and resource limits

Most APIs provide access to resources that are lists of entities such as /users or /widgets. A client such as a browser would typically filter and paginate through this list to limit the number items returned to a client like so:

First Call: GET /items?skip=0&take=10 
Second Call: GET /items?skip=10&take=10

However, if that entity has any PII or other information, then a hacker could scrape that endpoint to get a dump of all entities in your database. This could be most dangerous if those entities accidently exposed PII or other sensitive information, but could also be dangerous in providing competitors or others with adoption and usage stats for your business or provide scammers with a way to get large email lists. See how Venmo data was scraped

A naive protection mechanism would be to check the take count and throw an error if greater than 100 or 1000. The problem with this is two-fold:

  1. For data APIs, legitimate customers may need to fetch and sync a large number of records such as via cron jobs. Artificially small pagination limits can force your API to be very chatty decreasing overall throughput. Max limits are to ensure memory and scalability requirements are met (and prevent certain DDoS attacks), not to guarantee security.
  2. This offers zero protection to a hacker that writes a simple script that sleeps a random delay between repeated accesses.
skip = 0
while True:    response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip),                      headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})    print("Fetched 10 items")    sleep(randint(100,1000))    skip += 10

How to secure against pagination attacks

To secure against pagination attacks, you should track how many items of a single resource are accessed within a certain time period for each user or API key rather than just at the request level. By tracking API resource access at the user level, you can block a user or API key once they hit a threshold such as “touched 1,000,000 items in a one hour period”. This is dependent on your API use case and can even be dependent on their subscription with you. Like a Captcha, this can slow down the speed that a hacker can exploit your API, like a Captcha if they have to create a new user account manually to create a new API key.

Insecure API key generation

Most APIs are protected by some sort of API key or JWT (JSON Web Token). This provides a natural way to track and protect your API as API security tools can detect abnormal API behavior and block access to an API key automatically. However, hackers will want to outsmart these mechanisms by generating and using a large pool of API keys from a large number of users just like a web hacker would use a large pool of IP addresses to circumvent DDoS protection.

How to secure against API key pools

The easiest way to secure against these types of attacks is by requiring a human to sign up for your service and generate API keys. Bot traffic can be prevented with things like Captcha and 2-Factor Authentication. Unless there is a legitimate business case, new users who sign up for your service should not have the ability to generate API keys programmatically. Instead, only trusted customers should have the ability to generate API keys programmatically. Go one step further and ensure any anomaly detection for abnormal behavior is done at the user and account level, not just for each API key.

Accidental key exposure

APIs are used in a way that increases the probability credentials are leaked:

  1. APIs are expected to be accessed over indefinite time periods, which increases the probability that a hacker obtains a valid API key that’s not expired. You save that API key in a server environment variable and forget about it. This is a drastic contrast to a user logging into an interactive website where the session expires after a short duration.
  2. The consumer of an API has direct access to the credentials such as when debugging via Postman or CURL. It only takes a single developer to accidently copy/pastes the CURL command containing the API key into a public forum like in GitHub Issues or Stack Overflow.
  3. API keys are usually bearer tokens without requiring any other identifying information. APIs cannot leverage things like one-time use tokens or 2-factor authentication.

If a key is exposed due to user error, one may think you as the API provider has any blame. However, security is all about reducing surface area and risk. Treat your customer data as if it’s your own and help them by adding guards that prevent accidental key exposure.

How to prevent accidental key exposure

The easiest way to prevent key exposure is by leveraging two tokens rather than one. A refresh token is stored as an environment variable and can only be used to generate short lived access tokens. Unlike the refresh token, these short lived tokens can access the resources, but are time limited such as in hours or days.

The customer will store the refresh token with other API keys. Then your SDK will generate access tokens on SDK init or when the last access token expires. If a CURL command gets pasted into a GitHub issue, then a hacker would need to use it within hours reducing the attack vector (unless it was the actual refresh token which is low probability)

Exposure to DDoS attacks

APIs open up entirely new business models where customers can access your API platform programmatically. However, this can make DDoS protection tricky. Most DDoS protection is designed to absorb and reject a large number of requests from bad actors during DDoS attacks but still need to let the good ones through. This requires fingerprinting the HTTP requests to check against what looks like bot traffic. This is much harder for API products as all traffic looks like bot traffic and is not coming from a browser where things like cookies are present.

Stopping DDoS attacks

The magical part about APIs is almost every access requires an API Key. If a request doesn’t have an API key, you can automatically reject it which is lightweight on your servers (Ensure authentication is short circuited very early before later middleware like request JSON parsing). So then how do you handle authenticated requests? The easiest is to leverage rate limit counters for each API key such as to handle X requests per minute and reject those above the threshold with a 429 HTTP response. There are a variety of algorithms to do this such as leaky bucket and fixed window counters.

Incorrect server security

APIs are no different than web servers when it comes to good server hygiene. Data can be leaked due to misconfigured SSL certificate or allowing non-HTTPS traffic. For modern applications, there is very little reason to accept non-HTTPS requests, but a customer could mistakenly issue a non HTTP request from their application or CURL exposing the API key. APIs do not have the protection of a browser so things like HSTS or redirect to HTTPS offer no protection.

How to ensure proper SSL

Test your SSL implementation over at Qualys SSL Test or similar tool. You should also block all non-HTTP requests which can be done within your load balancer. You should also remove any HTTP headers scrub any error messages that leak implementation details. If your API is used only by your own apps or can only be accessed server-side, then review Authoritative guide to Cross-Origin Resource Sharing for REST APIs

Incorrect caching headers

APIs provide access to dynamic data that’s scoped to each API key. Any caching implementation should have the ability to scope to an API key to prevent cross-pollution. Even if you don’t cache anything in your infrastructure, you could expose your customers to security holes. If a customer with a proxy server was using multiple API keys such as one for development and one for production, then they could see cross-pollinated data.

#api management #api security #api best practices #api providers #security analytics #api management policies #api access tokens #api access #api security risks #api access keys

Autumn  Blick

Autumn Blick

1601381326

Public ASX100 APIs: The Essential List

We’ve conducted some initial research into the public APIs of the ASX100 because we regularly have conversations about what others are doing with their APIs and what best practices look like. Being able to point to good local examples and explain what is happening in Australia is a key part of this conversation.

Method

The method used for this initial research was to obtain a list of the ASX100 (as of 18 September 2020). Then work through each company looking at the following:

  1. Whether the company had a public API: this was found by googling “[company name] API” and “[company name] API developer” and “[company name] developer portal”. Sometimes the company’s website was navigated or searched.
  2. Some data points about the API were noted, such as the URL of the portal/documentation and the method they used to publish the API (portal, documentation, web page).
  3. Observations were recorded that piqued the interest of the researchers (you will find these below).
  4. Other notes were made to support future research.
  5. You will find a summary of the data in the infographic below.

Data

With regards to how the APIs are shared:

#api #api-development #api-analytics #apis #api-integration #api-testing #api-security #api-gateway