如今，相比編寫代碼，開發(fā)人員更可能為他們的應用程序組裝代碼。當然，他們仍會編寫關鍵的業(yè)務的代碼。但是，代碼庫中包含多達90％的開源或第三方組件，開發(fā)人員可將代碼重用于常見功能，節(jié)約時間。有一種可重用的組件類型是基于API的Web服務，其中許多可免費用于開發(fā)基本功能。但是，使用基于API的Web服務可能會產(chǎn)生版權、最終用戶許可、使用條款以及數(shù)據(jù)和隱私政策等相關問題。
開發(fā)人員經(jīng)常在互聯(lián)網(wǎng)上找到適用于其應用程序的有用API。但是軟件開發(fā)公司可能無法控制甚至不知道開發(fā)人員正在使用哪些API。然后，您的公司有一天決定購買該開發(fā)公司。您要如何在收購的時候減少基于API的Web服務的相關風險？
減少基于API的Web服務的4個方面的風險
當您考慮收購的公司有軟件需要進行實質性估值，而且此類軟件是基于API的Web服務時，需要注意以下4個方面：
- 法律和合規(guī)風險
- API安全風險
- 數(shù)據(jù)隱私風險
- 運營/業(yè)務風險
1.法律和合規(guī)風險
基于API的Web服務通常伴隨版權問題和使用條件，您需要了解這些版權和使用條件。使用條款也可能是復雜且不斷變化的。當使用條款更改時，用戶只要是繼續(xù)使用基于API的Web服務即表示同意新條款�？梢哉f，當您購買基于API的公司許可的Web服務時，您還可能繼承了其法律和合規(guī)風險。
2.API 安全風險
基于API的Web服務給收購方帶來了兩個風險：API發(fā)送的數(shù)據(jù)和接收的數(shù)據(jù)。發(fā)送的數(shù)據(jù)可能會泄漏或被竊聽；接收的數(shù)據(jù)可能包括可執(zhí)行文件、篡改的圖像、病毒或惡意代碼。而且，無論是發(fā)送還是接受的數(shù)據(jù)都可能受到中間人攻擊。
3.數(shù)據(jù)隱私風險
企業(yè)有時會將來自API的數(shù)據(jù)與從其它來源獲得的數(shù)據(jù)區(qū)別對待。當涉及到數(shù)據(jù)隱私時，所有數(shù)據(jù)，尤其是個人身份信息（PII），都需要同樣的保護。作為收購方，您必須對多方面進行盡職調查，包括目標應用程序如何處理API數(shù)據(jù)、如何將其與其它來源的匿名數(shù)據(jù)進行合并以及在何處（從地理角度而言）將數(shù)據(jù)發(fā)送至何處、從何處接收、存儲并處理等，還需要審查其是否遵守區(qū)域數(shù)據(jù)隱私法規(guī)，例如歐洲的《通用數(shù)據(jù)保護條例》（GDPR）。
4.運營/業(yè)務風險
基于API的Web服務是免費的，不提供服務級別協(xié)議（SLA）。在尋找潛在的收購機會時，您需要知道使用免費Web服務會帶來哪些持續(xù)的風險。如果吊銷了API許可證、不贊成使用API或競爭對手購買了API提供商并限制了直接競爭的訪問權限，您最終可能會遇到業(yè)務無法進展的問題。您必須制定應急計劃，以隨時應對API出于任何原因變得不可用的情況。
三個步驟緩解基于API的Web服務風險
與對開源軟件的審查一樣，收購方要降低基于API的Web服務風險，必須圍繞著全面披露和發(fā)現(xiàn)�；旧�，需要三個步驟：
- 識別應用程序中所有基于API的Web服務。明確地知道應用了哪些API，提供了哪些數(shù)據(jù)，它們的關聯(lián)許可證以及使用了多少和使用頻率。您可以通過詢問應用程序開發(fā)人員來獲取此信息，或者最好通過使用API /代碼掃描器對應用程序的API進行審核。
- 分析應用程序的API許可證。仔細檢查應用程序的API許可，以確保目標公司正確遵守合同條款。審查在理論上和現(xiàn)實中使用API是否有不一致之處。另外，請留意應該提供和實際提供的數(shù)據(jù)之間存在的任何差異。
- 制定補救計劃。補救計劃應涵蓋不同類別的問題，包括代碼、法律、冗余和突發(fā)事件、數(shù)據(jù)隱私和合同風險分配等。這將分別涉及由于服務中斷而更換API、尋求對現(xiàn)有許可證的補充或棄用、準備好API備份、向用戶群通知收集和傳輸了哪些數(shù)據(jù)，以及讓目標公司對交易中包含的基于API的Web服務提供具有約束力的證明和保證。
