可用资源
FC web api的web server只是一个接入层，计算层对接的是云厂商的FC运行时环境，可用资源受FC配额的限制，目前阿里云FC的默认配额是最高100个并发。另外，有一点需要注意的是，如果是计算密集型的功能，一定要将内存配额至少设为2G，这样才能保证可以用满一个核的算力。
传统web api的计算是直接在web server上完成，可用资源受web server所在云主机的限制。
运行环境
FC web api所对应的每一个method(FC)都可以有单独的运行环境，可以单独配置不同的软件依赖，也可以使用不同的技术栈。
传统web api的所有method都是在同一个环境里运行，远不如FC轻便灵活。
使用成本
FC web api仅需api网关常驻，后端对接的FC都是按每个FC的具体配额按0.1s的使用时间粒度收费。
传统web api的所有功能代码都需要常驻，即使无人调用，也要占用资源。
响应时间
FC web api经api网关触发FC(如果是自建web server作为api网关，需要调用sdk触发；如果是使用阿里云API网关服务，需要将函数配置为HTTP触发)，这一步有几毫秒的时间消耗，另外，当FC容器需要冷启动时，响应时间会大大增加，冷启动时间由函数镜像大小和初始化函数的耗费时间决定。
传统web api由于是常驻进程，没有网关触发FC的时间消耗及有可能遇到的冷启动等待，响应时间在一般情况下要优于FC web api，除非请求数量太多导致服务出现拥塞。
适用场景
FC web api适用于处理实时性要求不高的，较低频的请求。如上所述，FC的触发机制决定了响应时间可能存在一个较大范围的波动。另外，当FC被web api高频触发时，还存在到达资源配额上限(并发容器达到100个)导致其他FC无法正常运行的风险。例如，我们的web service是通过FC web api实现的，同时，监控该服务的告警发送动作也通过FC完成。那么，有可能当大流量涌入，FC资源被拉满，服务质量严重下降时，却会由于资源配额耗光的原因无法推送告警。
传统web api适用于处理要求实时性的高频请求。
