??? return n1 + n2;

}

const result = sum(10, 20);

// 異步

function getMsg() {

??? setTimeout(function () {

??????? return { msg: "Hello Node.js" };

??? }, 2000);

}

const msg = getMsg();

2、代碼執(zhí)行順序

司步API從上到下依次執(zhí)行,前面代碼會(huì)阻塞后面代碼的執(zhí)行;異步API不會(huì)等待API執(zhí)行完成后再向下執(zhí)行代碼。

for (var i = 0; i < 100000; i++) {

??? console.log(i);

}

console.log("for循環(huán)后面的代碼");

異步API不會(huì)等待API執(zhí)行完成后再向下執(zhí)行代碼

console.log("代碼開始執(zhí)行");

setTimeout(() => {

??? console.log("2秒后執(zhí)行的代碼");

}, 2000);

setTimeout(() => {

??? console.log('"0秒"后執(zhí)行的代碼');

}, 0);

console.log("代碼結(jié)束執(zhí)行");

3、回調(diào)函數(shù)

自己定義的函數(shù)讓別人去調(diào)用

// getData函數(shù)定義

function getData(callback) {}

// getData函數(shù)調(diào)用

getData(() => {});

4、使用回調(diào)函數(shù)獲取異步API執(zhí)行結(jié)果

function getMsg(callback) {

??? setTimeout(function () {

??????? callback({ msg: "Hello Node.js" });

??? }, 2000);

}

getMsg(function (msg) {

??? console.log(msg);

});

5、代碼執(zhí)行順序分析

console.log("代碼開始執(zhí)行");

setTimeout(() => {

??? console.log("2秒后執(zhí)行的代碼");

}, 2000);

setTimeout(() => {

??? console.log('"0秒"后執(zhí)行的代碼');

}, 0);

console.log("代碼結(jié)束執(zhí)行");

6、Node.js中的異步API

fs.readFile("./demo.txt", (err, result) => {});

var server = http.createServer();

server.on("request", (req, res) => {});

二者在實(shí)際應(yīng)用上,根據(jù)業(yè)務(wù)場景的不同,有著以下區(qū)別。

1.長時(shí)間運(yùn)行操作場景中,異步API更占優(yōu)勢。

以需要長時(shí)間運(yùn)行的業(yè)務(wù)為例,假設(shè)開發(fā)者正在構(gòu)建一個(gè)使用機(jī)器學(xué)習(xí)來檢測博客帖子情緒的 SaaS,開發(fā)者需要提交一個(gè)指向該博客帖子的鏈接,該服務(wù)將分析該帖子的情緒并將其返回。這個(gè)操作可能需要幾秒甚至一分鐘才能完成。可是這個(gè)時(shí)間太慢了,對于用戶來說,如果不能在 5 秒內(nèi)做出響應(yīng),就會(huì)失去耐心。因此,需要一個(gè)理解長時(shí)間運(yùn)行操作概念的 API。

若使用同步 API設(shè)計(jì),它的操作流程會(huì)是

“curl?-X?POST?-H?“Content-Type:?application/json”?-d?‘{“url”:?“https://www.wundergraph.com/blog/long_running_operations”}’?http://localhost:3000/api/v1/analyze_sentiment”

最終的響應(yīng)結(jié)果是

“{?“status”:?“success”,??“data”:?{???“url”:?“https://www.wundergraph.com/blog/long_running_oerations”,????“sentiment”:?“positive”??}}”

此操作可能需要很長時(shí)間才能完成,并且用戶可能會(huì)取消它。

若使用異步 REST API設(shè)計(jì),開發(fā)者需要返回具有唯一標(biāo)識符的響應(yīng),以便客戶端可以輪詢服務(wù)器以獲取結(jié)果。設(shè)計(jì)此類 API 的正確方法是返回 202 Accepted 狀態(tài)代碼。

因此開發(fā)者最終獲得的響應(yīng)效果將是一個(gè)帶有狀態(tài)代碼 202 和響應(yīng)。此刻,客戶端可以使用以下命令來獲取作業(yè)的狀態(tài):

curl?http://localhost:3000/api/v1/analyze_sentiment/1/status

意味著?API 的調(diào)用者可以及時(shí)獲取作業(yè)的當(dāng)前狀態(tài)或取消它。

隨著平臺(tái)功能的發(fā)展,用戶群體對精準(zhǔn)度更高的同步API需求同步增長。

以 Unity 首選的資源管理工具Addressable Asset System為例,它雖然可以將資源的引用和打包分開處理,加快運(yùn)行模式下和運(yùn)行版本的項(xiàng)目迭代。但是現(xiàn)有的許多Unity 用戶開發(fā)的游戲不會(huì)有遠(yuǎn)程下載內(nèi)容的需要,意味著異步行為在其它項(xiàng)目中反而會(huì)變成約束。因此,開發(fā)者需要新添功能更專一、準(zhǔn)確化程度更高的同步 API。

假設(shè)開發(fā)者新添加了Synchronous Addressables API,在 1.17.4 版的 Addressables 包中可以使用,兼容 Unity 2021.1、Unity 2020 LTS 和 Unity 2019 LTS。在有了新的 API 后,項(xiàng)目不必調(diào)整為異步加載就能用上 Addressables?了。同步行為在函數(shù)中以 AsyncOperationHandle 的 WaitForCompletion 方法表示,該方法會(huì)返回同步運(yùn)算的結(jié)果。

開發(fā)者可以先聲明 Addressables.LoadAssetAsync<GameObject>(“MyPrefab”),返回 GameObject 運(yùn)算的開關(guān) AsyncOperationHandle<GameObject>。這時(shí)再聲明 WaitForCompletion 會(huì)讓系統(tǒng)阻攔代碼執(zhí)行,直到資源加載完成。在加載完成后,WaitForCompletion 便會(huì)返回代碼請求的 GameObject。完成對異步和同步的同步運(yùn)算。

事實(shí)上,在大部分實(shí)例中,同步加載的性能可比肩異步加載。而且同步加載的準(zhǔn)確性更高。

在物聯(lián)網(wǎng)應(yīng)用中,二者的使用都有自己的優(yōu)勢

從聯(lián)網(wǎng)汽車和恒溫器到智能交通信號燈和農(nóng)場的作物管理,物聯(lián)網(wǎng)被用在各種部署中。物聯(lián)網(wǎng)設(shè)備通常會(huì)生成大量實(shí)時(shí)數(shù)據(jù),并使用流技術(shù)來保存這些數(shù)據(jù)。但這并不適用于向最終用戶提供數(shù)據(jù),因?yàn)槲锫?lián)網(wǎng)設(shè)備本身缺乏一種有效、安全的方法來將其數(shù)據(jù)公開給想要查看或分析數(shù)據(jù)的用戶。幸運(yùn)的是,這種情況正在改變。隨著事件原生 API 和API 網(wǎng)關(guān)的出現(xiàn),可以根據(jù)數(shù)據(jù)消費(fèi)者的需求,同步和異步地從 IoT 設(shè)備(以及各種其他資源)公開數(shù)據(jù)。

同步 API 是一種通過請求-響應(yīng)模型公開數(shù)據(jù)的 API。當(dāng)數(shù)據(jù)僅定期更改和/或當(dāng)數(shù)據(jù)消費(fèi)者不需要持續(xù)更新的信息流時(shí),這種方法可以根據(jù)數(shù)據(jù)消費(fèi)者的請求數(shù)據(jù)進(jìn)行響應(yīng),比如構(gòu)建一個(gè)報(bào)告室外溫度的應(yīng)用程序,同步 API?可以實(shí)時(shí)報(bào)告數(shù)據(jù);但是,如果處于數(shù)據(jù)不斷變化的環(huán)境內(nèi),異步API 會(huì)是更好的選擇,比如流經(jīng)管道的水量或機(jī)器人在工廠車間的位置不斷變化,使用異步 API,流數(shù)據(jù)可以通過 API 公開。這樣,數(shù)據(jù)消費(fèi)者可以使用 API 調(diào)用訪問持續(xù)更新的數(shù)據(jù)流,而無需直接連接到后端數(shù)據(jù)流。

參考鏈接:

https://mp.weixin.qq.com/s/bvoIptd7YwU45icqvoqokg

https://mp.weixin.qq.com/s/9c11pJ5d1nbE2vmGvCDwmQ

https://blog.csdn.net/cz_00001/article/details/132837290

https://mp.weixin.qq.com/s/OjmnK8LST7IavP5-9ByZZA

https://mp.weixin.qq.com/s/kw3huYO3XXtx30RCfwheAg

上一篇:

JSON API vs XML API:數(shù)據(jù)格式之爭

下一篇:

2024年P(guān)ython API框架:8個(gè)最佳開源選擇
#你可能也喜歡這些API文章!

我們有何不同?

API服務(wù)商零注冊

多API并行試用

數(shù)據(jù)驅(qū)動(dòng)選型,提升決策效率

查看全部API→
??

熱門場景實(shí)測,選對API

#AI文本生成大模型API

對比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力

25個(gè)渠道
一鍵對比試用API 限時(shí)免費(fèi)

#AI深度推理大模型API

對比大模型API的邏輯推理準(zhǔn)確性、分析深度、可視化建議合理性

10個(gè)渠道
一鍵對比試用API 限時(shí)免費(fèi)