可用資源
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適用於處理要求實時性的高頻請求。