本文來自微信公眾號“開源云中文社區(qū)”。
今年P(guān)ostman State of the API調(diào)查顯示，人們擔(dān)心微服務(wù)會擴(kuò)展為難以處理的混亂和僵尸API。但即使存在這些問題，調(diào)查也發(fā)現(xiàn)，API為組織帶來了回報(bào)——在40000名受訪者中，近三分之二的人表示API帶來了收入。
43%的受訪者表示，API占公司收入的四分之一以上。對于少數(shù)幾家公司來說，API創(chuàng)造了超過75%的總收入。報(bào)告指出，這些公司屬于金融服務(wù)業(yè)的可能性幾乎是其他行業(yè)的兩倍。
考慮到API的盈利能力，不難理解為什么92%的全球受訪者表示API投資將在未來12個(gè)月內(nèi)增加或保持不變。這比去年的報(bào)告上升了三個(gè)百分點(diǎn)。
報(bào)告指出：“這一增長可能反映出科技行業(yè)最嚴(yán)重的經(jīng)濟(jì)收縮已經(jīng)過去。與此同時(shí)，更少的受訪者表示，他們預(yù)計(jì)今年將削減對API的投資。”
微服務(wù)、中間服務(wù)和單體
在大多數(shù)組織中，微服務(wù)仍然是API的主要架構(gòu)風(fēng)格，但這似乎并不總是按計(jì)劃進(jìn)行。在今年的報(bào)告中，10%的受訪者表示，為微服務(wù)提供動(dòng)力的API變得龐大而笨拙，創(chuàng)造了“宏服務(wù)”而不是微服務(wù)。
微服務(wù)被定義為獨(dú)立工作以履行單一職責(zé)的小型服務(wù)，而宏服務(wù)則被定義為變得龐大而笨拙的微服務(wù)，接近于單體。單體是一種單層應(yīng)用程序，其中接口和數(shù)據(jù)訪問結(jié)合在一個(gè)包中。而中間服務(wù)是Goldilock的偏好：不要太大，也不要太小——恰到好處。
單體和中間服務(wù)各占所調(diào)查組織的20%多一點(diǎn)。
Postman聯(lián)合創(chuàng)始人兼首席技術(shù)官Ankit Sobti在接受采訪時(shí)表示：“很明顯，十年來，微服務(wù)成為主流。我們想通過調(diào)查來展現(xiàn)微服務(wù)發(fā)展壯大、變得笨拙，并從一開始就失去了微服務(wù)的本質(zhì)。”
使用微服務(wù)的一個(gè)原因是，理論上微服務(wù)及其API可以更容易地重用。因此值得注意的是，21%的自稱“API優(yōu)先”的領(lǐng)導(dǎo)者表示，重用API或微服務(wù)是組織的痛點(diǎn)。
Sobti說：“可重用性的方面是API的可使用性，我們與客戶交談時(shí)看到的困難，首先是發(fā)現(xiàn)API之外的問題。API是否一致、符合要求且易于設(shè)置？身份驗(yàn)證在剛開始使用API時(shí)最終會成為一個(gè)大問題。因此，我認(rèn)為驅(qū)動(dòng)API使用的因素對API難以集成到網(wǎng)絡(luò)中的方式產(chǎn)生了很大影響。”
僵尸API因裁員而興起
近60%的受訪者擔(dān)心僵尸API——這些API缺乏適當(dāng)?shù)奈臋n和所有權(quán)，但在開發(fā)人員離開組織后仍然存在。當(dāng)開發(fā)人員離開時(shí)，它被列為第二大關(guān)注點(diǎn)，僅次于糟糕的文檔。工程師和開發(fā)人員將僵尸API列為令人擔(dān)憂的問題。
報(bào)告指出：“這些API沒有所有者、監(jiān)督或維護(hù)，有時(shí)會被公司遺忘。往壞了說，僵尸API帶來了安全風(fēng)險(xiǎn)；往好了說，它們提供了糟糕的消費(fèi)者體驗(yàn)。”
Sobti建議，一種解決方案是維護(hù)所使用的API目錄。
Sobti說：“這就是僵尸API的出現(xiàn)，因?yàn)楹芏嘀R都掌握在構(gòu)建它的人身上。一旦員工離職，變更管理就變得很復(fù)雜，因此對API內(nèi)部API進(jìn)行編目就變得尤為重要。”
他補(bǔ)充道，API目錄可以在一個(gè)地方跟蹤內(nèi)部API?，F(xiàn)在有專門的團(tuán)隊(duì)不僅負(fù)責(zé)構(gòu)建允許目錄存在的底層基礎(chǔ)設(shè)施，還負(fù)責(zé)管理目錄和創(chuàng)建構(gòu)建實(shí)踐，以將這些API放入目錄。這就是重用變得至關(guān)重要的地方，他補(bǔ)充道。
調(diào)查發(fā)現(xiàn)，缺乏文檔是使用API的主要障礙，這進(jìn)一步證明了需要更好的文檔。
一半的受訪者表示，不到1/20的API變更失敗。在行業(yè)中，醫(yī)療保健行業(yè)的比例最高，55%的受訪者表示，不到1/20的API部署失敗。教育處于另一端；只有43%的受訪者表示他們的失敗率那么高。也許這與另一個(gè)關(guān)鍵發(fā)現(xiàn)有關(guān)：教育也是最有可能跳過API測試并將最后一段時(shí)間用于API開發(fā)的部門。
API優(yōu)先領(lǐng)導(dǎo)者遭遇失敗的可能性低于所有受訪者，60%的受訪者表示失敗發(fā)生率不到1/20。
API-First開發(fā)
該報(bào)告還注意到，被稱為API優(yōu)先的公司在各種API問題上的表現(xiàn)優(yōu)于非API優(yōu)先的公司。API優(yōu)先的公司在開發(fā)過程開始時(shí)優(yōu)先考慮API，將API定位為軟件的構(gòu)建塊。超過75%的受訪者多少同意或強(qiáng)烈同意API優(yōu)先的公司的開發(fā)人員生產(chǎn)效率更高，創(chuàng)建更好的軟件，并更快地與合作伙伴集成。
根據(jù)Postman的說法，API優(yōu)先意味著在編寫其他代碼之前開發(fā)API，而不是將其視為事后考慮。
Sobti表示：“API優(yōu)先的公司承認(rèn)API是其軟件戰(zhàn)略的基石。因此，你正在考慮一種開發(fā)模型，在該模型中，應(yīng)用程序被概念化為內(nèi)部和外部服務(wù)與這些API的互連。API優(yōu)先的組織正越來越認(rèn)識到API的業(yè)務(wù)和技術(shù)含義。”
公司正在意識到API對業(yè)務(wù)的戰(zhàn)略價(jià)值。他說，更多公司報(bào)告稱，API在公司今年的收入中占了很大一部分。調(diào)查還發(fā)現(xiàn)，收入是API訪問的第二重要指標(biāo)，僅次于使用本身。調(diào)查發(fā)現(xiàn)，隨著公司規(guī)模和開發(fā)商數(shù)量的增長，API優(yōu)先的公司的收益也會增加。
報(bào)告稱：“在開發(fā)人員不超過100人的小型公司中，32%的受訪者強(qiáng)烈認(rèn)為API優(yōu)先的公司上市速度更快。但隨著開發(fā)人員人數(shù)超過100人，這一數(shù)字穩(wěn)步攀升。當(dāng)一家公司的開發(fā)者達(dá)到5000人時(shí)，42%的受訪者強(qiáng)烈同意這一說法。當(dāng)按公司規(guī)模排序時(shí)，我們看到幾乎所有指標(biāo)都有類似的增長。”
他說：“從技術(shù)上講，我們看到API優(yōu)先的公司能夠更快地構(gòu)建API，報(bào)告更少的故障，當(dāng)API出現(xiàn)故障時(shí)，他們能夠在不到一個(gè)小時(shí)的時(shí)間內(nèi)恢復(fù)和響應(yīng)。我們看到的是，API在組織內(nèi)部和外部的數(shù)量肯定在增加，其中一部分是能夠重用在組織內(nèi)部以及外部創(chuàng)建的更多功能，你現(xiàn)在可以使用、訂閱或購買這些功能。”
他說，利用重用是驅(qū)動(dòng)開發(fā)人員用更少的人力做更多事情的能力，無論是用更少的人做更少的事，還是因?yàn)殚_發(fā)人員不必創(chuàng)建業(yè)務(wù)功能，因?yàn)樗麄兛梢杂嗛哠tripe并通過Stripe的API實(shí)際管理賬單。
GraphQL提高了API架構(gòu)的地位
該報(bào)告指出，調(diào)查還發(fā)現(xiàn)，盡管REST仍是目前使用最多的API架構(gòu)，但它對新來者來說已經(jīng)失去了地位。今年，86%的受訪者表示他們使用了REST，低于去年報(bào)告的89%和前年的92%。
SOAP的使用率從去年的34%下降到今年的26%。取代SOAP的是GraphQL，29%的受訪者使用了它。
當(dāng)談到API規(guī)范時(shí)，JSON模式是最受歡迎的，其次是Swagger/OpenAPI 2.0和Open API 3.x幾乎平分秋色。GraphQL排名第四。
原文鏈接：
https://thenewstack.io/state-of-the-api-microservices-gone-macro-and-zombie-apis/
