我花了整个上午的时间试图弄清楚这一点。我有一个Web API项目(.NET5(，它有许多控制器。我的任务是将其划分为使用Azure功能的微服务，而不是应用程序服务。一个控制器中有三个端点：
[HttpGet("history/{country}/{stateProvince}/{countyRegion}")]
IActionResult GetByCounty(string country, string stateProvince, string countyRegion)
[HttpGet("history/{country}/{stateProvince}")]
IActionResult GetByState(string country, string stateProvince)
[HttpGet("history/postalcodes/{country}/{postalCode}")]
IActionResult GetByPostalCode(string country, string postalCode)
一切都很好，一切都如预期。在功能应用程序中，我定义了三个HTTP触发器：
HttpResponseData GetByCounty([HttpTrigger(Route = "history/{country}/{stateProvince}/{countyRegion}")]
HttpResponseData GetByPostalCode([HttpTrigger(Route = "history/postalcodes/{country}/{postalCode}")]
HttpResponseData GetByState([HttpTrigger(Route = "history/{country}/{stateProvince}")]
GetByState和GetByCounty运行良好。然而，当试图在功能应用程序中通过邮政编码获取时，正在执行GetByCounty功能。Web API应用程序正在遵守静态文本"；postalcodes">在路线中。函数应用程序不是。它看到路径上有四个级别，并按字母顺序选择第一个级别，恰好是GetByCounty。
除了添加一个不必要的路径以使级别的数量是唯一的之外，有没有一种方法可以实现这一点，从而执行正确的HTTP触发器？
- 将GetByPostalCode更改为"；山核桃/postalcodes/{country}/{postalcode}作品
- 将GetByPostalCode更改为"；postalcodes/history/{country}/{postalcode}作品
- 添加一个附加的路径级别"；历史/postalcodes/countries/{country}/{postalcode}作品
但这在兼容性方面破坏了API，这不是一件好事。
Azure函数和Web API看起来非常相似，因为它们都接受HTTP请求，处理它并返回响应，而且似乎Web API可以很容易地迁移到Azure函数。但是，
HTTP触发器功能不等于Web API操作
- 每个Azure函数在设计上都有一个静态修饰符，而WebAPI没有静态修饰符
- 此外，Azure函数是Azure WebJobs的扩展，WebJobs可以不使用静态修饰符
-
Web API控制器内部创建一个HttpContext实例来处理数据，如头、Cookie、会话查询字符串和请求主体等，其中HttpContext实例作为内部属性，因此任何操作都可以直接访问它。
-
Azure Function从Web API获取不同的HTTP请求/响应，该API将参数作为HttpRequestMessage实例。它不负责cookie或会话，只处理头、查询字符串和请求体。
在路由方面：
- 一些decorator在每个操作上使用
HttpGet, HttpPut, HttpPatch and HttpDelete，通过与Web API中的路由decorator组合来声明哪些HTTP谓词执行操作 - 并且基本URL将在Web API的控制器级别上定义
- 这是使用Azure函数创建创建的两个文件，即
function.json和host.json function.json包含每个函数HTTP动作定义的路由。有了这个定义，具有相同路由URI的不同函数可以处理基于HTTP谓词的请求- Azure函数中没有控制器。因此，在
host.json中定义的函数端点URI的默认值为api，但我们可以使用host.json修改路由URI，如下所示：
{
"http": {
"routePrefix": "" // prefix, "api", is removed.
}
}
Azure函数在这些类型的场景中通过Web API大多是有益的，如：
- 如果Web API是为微服务架构设计的
- 如果Web API需要很长时间才能响应
- 如果Web API需要大量的精力来重构体系结构