• 1. RPC：調(diào)用另一個(gè)系統(tǒng)的函數(shù)
• RPC 的工作機(jī)制
• RPC 的優(yōu)勢
• RPC 的不足
• RPC 的用例
• 2. SOAP：使數(shù)據(jù)作為服務(wù)可用
• SOAP 的工作機(jī)制
• SOAP 的優(yōu)勢
• SOAP 的不足
• SOAP 的用例
• 3. REST：使數(shù)據(jù)作為資源可用
• REST 的工作機(jī)制
• REST 的優(yōu)勢
• REST 的不足
• REST 的用例
• 4. GraphQL：僅請求所需要的數(shù)據(jù)
• GraphQL 的工作機(jī)制
• GraphQL 的優(yōu)勢
• GraphQL 的不足
• GraphQL 的用例
• 5. 哪種 API 模式最適用你的用例？

本文討論了四種主要的 API 架構(gòu)風(fēng)格，比較它們的優(yōu)缺點(diǎn)，并重點(diǎn)介紹每種情況下最適合的 API 架構(gòu)風(fēng)格。

兩個(gè)單獨(dú)的應(yīng)用程序需要中介程序才能相互通信。因此，開發(fā)人員經(jīng)常需要搭建橋梁——也就是應(yīng)用程序編程接口（API），來允許一個(gè)系統(tǒng)訪問另一個(gè)系統(tǒng)的信息或功能。

為了快速、大規(guī)模地集成不同的應(yīng)用程序，API 使用協(xié)議或規(guī)范來定義那些通過網(wǎng)絡(luò)傳輸?shù)南⒌恼Z義和信息。這些規(guī)范構(gòu)成了 API 的體系結(jié)構(gòu)。

在過去，人們已經(jīng)發(fā)布了多種不同的 API 架構(gòu)風(fēng)格。每個(gè)架構(gòu)風(fēng)格都有它獨(dú)有的標(biāo)準(zhǔn)化數(shù)據(jù)交換的模式。這一系列的 API 架構(gòu)風(fēng)格的選項(xiàng)，引發(fā)了大量的關(guān)于哪種架構(gòu)風(fēng)格才是最好的爭論。

今天，許多 API 的使用者將 REST 稱作“消亡的 REST”（REST in peace），并且為 GraphQL 感到歡欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的贏家。這些觀點(diǎn)的問題在于，它們的出發(fā)點(diǎn)只是為某種技術(shù)背書，而不是去考慮它實(shí)際的屬性和特性如何與當(dāng)前的需求相匹配。

1. RPC：調(diào)用另一個(gè)系統(tǒng)的函數(shù)

遠(yuǎn)程過程調(diào)用是一種允許在不同上下文中遠(yuǎn)程執(zhí)行函數(shù)的規(guī)范。RPC 擴(kuò)展了本地過程調(diào)用的概念，并將其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在問題的，因?yàn)楹茈y確保 XML 有效負(fù)載的數(shù)據(jù)類型。因此，后來 RPC API 開始使用一個(gè)更具體的 JSON-RPC 規(guī)范，該規(guī)范被認(rèn)為是 SOAP 的更簡單的替代方案。gRPC 是 Google 在 2015 年開發(fā)的最新 RPC 版本。gRPC 可插拔支持負(fù)載均衡、追蹤、運(yùn)行狀況檢查和身份驗(yàn)證，它非常適合連接不同的微服務(wù)。

RPC 的工作機(jī)制

客戶端調(diào)用一個(gè)遠(yuǎn)程的過程，將參數(shù)和附加信息序列化為消息，然后將消息發(fā)送到服務(wù)端。服務(wù)端在接受到消息后，將信息的內(nèi)容反序列化，執(zhí)行所請求的操作，然后將結(jié)果發(fā)送回客戶端?？蛻舳撕头?wù)端各自負(fù)責(zé)參數(shù)的序列化和反序列化。

RPC 的優(yōu)勢

簡單直接的交互。 RPC 使用 GET 來獲取信息，使用 POST 來處理其他所有操作。服務(wù)端和客戶端之間交互的機(jī)制歸結(jié)為調(diào)用端點(diǎn)并獲得響應(yīng)。

易于添加新函數(shù)。 如果 API 有了新的需求，我們可以輕松地添加另一個(gè)執(zhí)行這個(gè)需求的端點(diǎn)：1）編寫一個(gè)新函數(shù)，并將其放在一個(gè)新端點(diǎn)之后；2）現(xiàn)在，客戶可以訪問這個(gè)端點(diǎn)，并獲取符合其需求的信息。

高性能 。輕量級的有效負(fù)載不會(huì)對網(wǎng)絡(luò)產(chǎn)生壓力，以此提供高性能，這對于共享服務(wù)器和在工作站網(wǎng)絡(luò)上執(zhí)行并行計(jì)算非常重要。RPC 還能夠優(yōu)化網(wǎng)絡(luò)層，使得不同服務(wù)之間每天發(fā)送海量消息變得非常高效。

RPC 的不足

和底層系統(tǒng)緊密耦合。 API 的抽象級別有助于其可重用性。API 與基礎(chǔ)系統(tǒng)的耦合越緊密，對其他系統(tǒng)的可重用性就越差。RPC 與基礎(chǔ)系統(tǒng)的緊密耦合不允許其在系統(tǒng)函數(shù)和外部 API 之間建立抽象層。這很容易引起安全問題，因?yàn)殛P(guān)于基礎(chǔ)系統(tǒng)的細(xì)節(jié)實(shí)現(xiàn)很容易會(huì)泄漏到 API 中。

RPC 的緊密耦合使得可伸縮性要求和松散耦合的團(tuán)隊(duì)難以實(shí)現(xiàn)。因此，客戶端要么會(huì)擔(dān)心調(diào)用特定端點(diǎn)的帶來的任何可能的副作用，要么需要嘗試弄清楚要調(diào)用的端點(diǎn)，因?yàn)榭蛻舳瞬涣私夥?wù)器如何命名其函數(shù)。

可發(fā)現(xiàn)性低。 在 RPC 中，無法對 API 進(jìn)行檢驗(yàn)總結(jié)，或者發(fā)送請求來開始理解根據(jù)需求應(yīng)該調(diào)用哪個(gè)函數(shù)。

函數(shù)爆炸性增長 。創(chuàng)建新函數(shù)非常容易。因此，相較于重新編輯現(xiàn)有的函數(shù)，我們會(huì)傾向于創(chuàng)建新的功能，最終產(chǎn)生大量難以理解的、功能重疊的函數(shù)。

RPC 的用例

RPC 模式在八十年代開始使用，但這并不意味著它已經(jīng)過時(shí)了。諸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）這樣的大公司如今正在內(nèi)部使用高性能的 RPC 版本，來執(zhí)行極高性能、低開銷的消息傳遞。它們龐大的微服務(wù)系統(tǒng)要求內(nèi)部通信在使用短消息的情況下也保持清晰。

命令 API 。RPC 是用于將命令發(fā)送到遠(yuǎn)程系統(tǒng)的正確選擇。例如，Slack API 是非常以命令為中心的：加入頻道、離開頻道、發(fā)送消息。因此，Slack API 的設(shè)計(jì)者以類似于 RPC 的樣式對其進(jìn)行了建模，使其小巧、緊湊并且易于使用。

用于內(nèi)部微服務(wù)的客戶特定的 API 。由于是在單個(gè)提供者和單個(gè)使用者之間建立直接的集成，我們不想像 REST API 那樣，花太多時(shí)間通過網(wǎng)絡(luò)傳輸大量的元數(shù)據(jù)。憑借高消息速率和消息性能，gRPC 和 Twirp 成為了用于微服務(wù)的可靠用例。通過在底層使用 HTTP 2，gRPC 能優(yōu)化網(wǎng)絡(luò)層，使其非常高效地在不同服務(wù)之間每天傳送大量信息。然而，如果你并不是要著眼于提高網(wǎng)絡(luò)性能，而是要在發(fā)布高度獨(dú)立的微服務(wù)團(tuán)隊(duì)之間建立一個(gè)穩(wěn)定的 API 聯(lián)系。REST 就能做到。

2. SOAP：使數(shù)據(jù)作為服務(wù)可用

SOAP 是一個(gè) XML 格式的、高度標(biāo)準(zhǔn)化的網(wǎng)絡(luò)通訊協(xié)議。在 XML-RPC 發(fā)布的一年后，SOAP 由微軟發(fā)布、并繼承了許多 XML-RPC 的特性。在 REST 緊隨其后發(fā)布，一開始它們是被同時(shí)使用，但很快 REST 贏得了這次比賽，成為了更流行的協(xié)議。

SOAP 的工作機(jī)制

XML 數(shù)據(jù)格式拖累了很多數(shù)據(jù)規(guī)范。伴隨著大量的消息結(jié)構(gòu)，XML 數(shù)據(jù)格式使得 SOAP 成為了最冗長的 API 架構(gòu)風(fēng)格。

SOAP 的消息由這些部件組成：

• 一個(gè)信封標(biāo)簽：用于開始和結(jié)束每條消息
• 包含請求或響應(yīng)的正文
• 一個(gè)標(biāo)頭：用于表示消息是否由某些規(guī)范或額外要求的來確認(rèn)
• 故障通知：包含了可能在請求處理過程只能夠發(fā)生的任何錯(cuò)誤

SOAP API 的邏輯由 Web 服務(wù)描述語言（WSDL）編寫。該 API 描述語言定義了端點(diǎn)并描述了可以執(zhí)行的所有過程。這使得不同的編程語言和 IDE 能夠快速建立通信。

SOAP 支持有狀態(tài)和無狀態(tài)消息傳遞。在有狀態(tài)的情況下，服務(wù)器存儲接收到的信息可能非常繁瑣復(fù)雜。但這對于涉及多方和復(fù)雜交易的操作是合理的。

SOAP 的優(yōu)勢

獨(dú)立于語言和平臺 。內(nèi)置創(chuàng)建 Web 服務(wù)的功能使得 SOAP 能夠處理消息通信的同時(shí)發(fā)送獨(dú)立于語言和平臺響應(yīng)。

綁定到各種協(xié)議 。SOAP 在適用于多種場景的傳輸協(xié)議方面是十分靈活的。

內(nèi)置錯(cuò)誤處理 。SOAP API 規(guī)范允許返回帶有錯(cuò)誤碼及其說明的的 XML 重試消息。

一系列的安全拓展 。SOAP 與 ES-Security 集成，因此 SOAP 可滿足企業(yè)級事務(wù)要求。它在事務(wù)內(nèi)部提供了隱私和完整性，同時(shí)允許在消息級別進(jìn)行加密。

SOAP 的不足

如今，由于如下幾種原因，許多開發(fā)人員在聽到必須集成 SOAP API 的想法后都會(huì)感到不安。

僅使用 XML 。SOAP 消息包含大量的元數(shù)據(jù)，并且在請求和響應(yīng)時(shí)僅支持繁冗的 XML 格式。

重量級 。由于 XML 文件的大小，SOAP 服務(wù)需要很大的帶寬。

非常專業(yè)化的知識 。構(gòu)建 SOAP API 服務(wù)器需要對所有涉及到的協(xié)議以及它們及其嚴(yán)格的限制都有很深的了解。

乏味的消息更新 。由于需要額外的工作來添加或者刪除某個(gè)消息屬性，這種死板的 SOAP 模式減慢了其被采用的速度。

SOAP 的用例

目前，SOAP 體系結(jié)構(gòu)最常用于企業(yè)內(nèi)部或與其信任的合作伙伴的內(nèi)部集成。

高度安全的數(shù)據(jù)傳輸 。SOAP 嚴(yán)格的消息結(jié)構(gòu)，安全性和授權(quán)功能使其成為在 API 和客戶端之間執(zhí)行正式軟件協(xié)議的最合適的選擇，同時(shí)又符合 API 提供者與 API 使用者之間的法律合同。這就是為什么金融組織和其他企業(yè)用戶選擇適用 SOAP 的原因。

3. REST：使數(shù)據(jù)作為資源可用

REST 如今是一種無需解釋的 API 架構(gòu)風(fēng)格，它由一系列的架構(gòu)約束所定義，旨在被廣泛 API 使用者采用。

當(dāng)前最常見的 API 架構(gòu)風(fēng)格最初時(shí)由 Roy Fielding 在其博士論文中提出的。REST 使得服務(wù)端的數(shù)據(jù)可用，并以簡單的格式（通常是 JSON 和 XML）來表示它。

REST 的工作機(jī)制

REST 的定義并不像 SOAP 那樣嚴(yán)格。RESTful 體系結(jié)構(gòu)應(yīng)該遵守如下六個(gè)體系結(jié)構(gòu)約束：

• 統(tǒng)一接口：無論設(shè)備或應(yīng)用程序類型如何，都可以采用統(tǒng)一的方式與給定的服務(wù)端進(jìn)行交互。
• 無狀態(tài)：請求本身包含處理該請求所需要的狀態(tài)，并且服務(wù)端不存儲與會(huì)話相關(guān)的任何內(nèi)容。
• 緩存
• 客戶端 - 服務(wù)器體系結(jié)構(gòu)：允許雙方獨(dú)立發(fā)展
• 應(yīng)用程序的層級系統(tǒng)
• 服務(wù)端向客戶端提供可執(zhí)行代碼的能力

實(shí)際上，某些服務(wù)僅在某種程度上是 RESTful 的。而它們的內(nèi)核采用了 RPC 樣式，將較大的服務(wù)分解為資源，并有效地使用 HTTP 基礎(chǔ)結(jié)構(gòu)。但 REST 的關(guān)鍵部分是超媒體（又稱 HATEOAS），是超文本作為應(yīng)用程序狀態(tài)引擎（Hypertext As The Enginer Of Application State）的縮寫。基本來說，這意味著 REST API 在每個(gè)響應(yīng)中都提供元數(shù)據(jù)，該元數(shù)據(jù)鏈接了有關(guān)如何使用該 API 的所有相關(guān)信息。這樣便可以使客戶端和服務(wù)端解耦。因此，API 提供者和 API 使用者都可以獨(dú)立發(fā)展，而這并不會(huì)阻礙他們的交流。

“HATEOAS 才是 REST 的關(guān)鍵功能，因?yàn)樗嬲沟?REST 成為 REST。但由于大多數(shù)人不使用 HATEOAS，因此他們實(shí)際上是在使用 HTTP RPC?！边@是 Reddit 上表達(dá)的一些激進(jìn)觀點(diǎn)。確實(shí)，HATEOAS 是 REST 的最成熟版本。

但是，這非常難以實(shí)現(xiàn)，因?yàn)檫@要求 API 客戶端要比它們?nèi)缃駱?gòu)建和使用的方式變得更先進(jìn)和智能得多。因此，即便是如今非常好的 REST API 也不一定總是能做到這一點(diǎn)。這就是為什么 HATEOAS 主要是作為 RESTful API 設(shè)計(jì)的長期開發(fā)的愿景而存在。

當(dāng)服務(wù)端實(shí)現(xiàn) REST 的某些功能和 RPC 的某些功能時(shí)，在 REST 和 RPC 之間確實(shí)可能存在這樣一個(gè)灰色區(qū)域。但 REST 是基于資源或名詞的，而不是基于動(dòng)作或動(dòng)詞。

在 REST 中，使用例如 GET、POST、PUT、DELETE、OPTIONS 可能還有 PATCH 等 HTTP 方法來完成操作。

REST 的優(yōu)勢

客戶端和服務(wù)端的解耦 ：由于 REST 盡可能地解耦了客戶端和服務(wù)端，REST 相較于 RPC 可以提供更好的抽象性。具有抽象級別的系統(tǒng)能夠封裝其實(shí)現(xiàn)細(xì)節(jié)，以更好的標(biāo)示和維持它的屬性。這使得 REST API 足夠靈活，可以隨著時(shí)間的推移而發(fā)展，同時(shí)保持穩(wěn)定的系統(tǒng)。

可發(fā)現(xiàn)性 ：客戶端和服務(wù)端之間的通信描述了所有內(nèi)容，因此不需要外部文檔即可了解如何與 REST API 進(jìn)行交互。

緩存友好 ：REST 重用了許多 HTTP 工具，也是唯一一種可以在 HTTP 層面上緩存數(shù)據(jù)的 API 架構(gòu)風(fēng)格。與其相對的是，在任何其他 API 上實(shí)現(xiàn)緩存都需要配置其他緩存模塊。

多種格式支持 ：REST 擁有支持多種格式用于存儲和交換數(shù)據(jù)的能力，這是它如今成為搭建公共 API 的主要選擇的原因之一。

REST 的不足

沒有標(biāo)準(zhǔn)的 REST 結(jié)構(gòu) ：在構(gòu)建 REST API 方面，沒有具體的正確方法。如何對資源進(jìn)行建模以及哪些資源需要建模取決于不同的情況。這使得 REST 在理論上很簡單，但在實(shí)踐中卻很困難。

龐大的負(fù)載： REST 會(huì)返回大量豐富的元數(shù)據(jù)，以便客戶端可以僅從響應(yīng)中了解有關(guān)應(yīng)用程序狀態(tài)的所有必要信息。對于具有大量帶寬容量的大型網(wǎng)絡(luò)系統(tǒng)來說，這種“啰嗦”的通信并不算很大的負(fù)載。但帶寬容量并非總是足夠的。這也是 Facebook 在 2012 年提出 GraphQL 架構(gòu)風(fēng)格的關(guān)鍵驅(qū)動(dòng)因素。

響應(yīng)過度和響應(yīng)不足問題 。REST 的響應(yīng)包含的數(shù)據(jù)會(huì)過多或不足，通常會(huì)導(dǎo)致客戶端需要發(fā)送另一個(gè)請求。

REST 的用例

管理 API 。在系統(tǒng)中，專注于管理對象并面向許多使用者的 API 是最常見的 API 類型。REST 幫助此類 API 具有強(qiáng)大的可發(fā)現(xiàn)性，良好的文檔編制，因此 REST 非常適合此對象模型。

簡單的資源驅(qū)動(dòng)型應(yīng)用程序 。在用于連接不需要查詢靈活性的資源驅(qū)動(dòng)型應(yīng)用時(shí)，REST 是一種非常有效的方法。

4. GraphQL：僅請求所需要的數(shù)據(jù)

REST API 需要被多次調(diào)用才能返回所需要的資源。所以，GraphQL 被發(fā)明了，并改變了這一切游戲的規(guī)則。

GraphQL 是一種語法，它描述了如何進(jìn)行精確的數(shù)據(jù)請求。有些應(yīng)用程序的數(shù)據(jù)模型具有許多相互引用的復(fù)雜實(shí)體，在這種情況下，實(shí)現(xiàn) GraphQL 是值得的。

如何從 GraphQL 端點(diǎn)僅獲取所需要的數(shù)據(jù)，圖源：Mohit Tikoo

如今，GraphQL 的生態(tài)系統(tǒng)正在蓬勃發(fā)展，出現(xiàn)了例如 Apollo、GraphiQL 和 GraphQL Explorer 等強(qiáng)大的庫和工具。

GraphQL 的工作機(jī)制

GraphQL 從構(gòu)建模式（Schema）開始。模式是對于用戶可以在 GraphQL API 中進(jìn)行的所有查詢及其返回的所有類型的描述。模式構(gòu)建非常困難，因?yàn)樗枰褂媚Ｊ蕉x語言（SDL）進(jìn)行強(qiáng)類型化。

因?yàn)樵诳蛻舳诉M(jìn)行查詢之前已經(jīng)定義好了模式，所以客戶端可以驗(yàn)證其查詢語句，以確保服務(wù)端能夠?qū)Σ樵冋Z句進(jìn)行響應(yīng)。在查詢語句到達(dá)后端應(yīng)用程序時(shí)，GraphQL 操作將根據(jù)整個(gè)模式進(jìn)行解釋，并向前端應(yīng)用程序返回解析到的數(shù)據(jù)。API 向服務(wù)端發(fā)送一個(gè)龐大的查詢，該 API 返回一個(gè)僅包含我們所需數(shù)據(jù)的 JSON 響應(yīng)。

GraphQL 的查詢語句執(zhí)行，圖源：Jonas Helfer

除了包含 RESTful 的 CRUD 操作，GraphQL 還有訂閱（subscriptions）機(jī)制，允許接收來自服務(wù)端的實(shí)時(shí)通知。

GraphQL 的優(yōu)勢

具有類型的模式 ：GraphQL 提前公開了它能做什么，從而提高了其可發(fā)現(xiàn)性。通過將客戶端指向 GraphQL API，我們可以發(fā)現(xiàn)什么查詢語句是可用的。

沒有版本控制 ：版本控制的最佳實(shí)踐是不要對 API 進(jìn)行版本控制。

盡管 REST 提供了不同的 API 版本，GraphQL 使用的是不斷更新的單一版本，這使用戶可以持續(xù)訪問新功能，并有助于提供更整潔、更可維護(hù)的服務(wù)器代碼。

詳細(xì)的錯(cuò)誤消息 ：GraphQL 以類似于 SOAP 的方式提供所發(fā)生錯(cuò)誤的詳細(xì)信息。它的錯(cuò)誤消息包括所有解析器，并指向確切的發(fā)生故障時(shí)的查詢部分。

靈活的權(quán)限 ：GraphQL 允許選擇性地公開某些功能，同時(shí)保留私人信息。而相對應(yīng)的是，REST 體系架構(gòu)不能僅顯示部分?jǐn)?shù)據(jù)，要么是全部數(shù)據(jù)，要么是沒有數(shù)據(jù)。

GraphQL 的不足

性能問題 。GraphQL 權(quán)衡了復(fù)雜性，來實(shí)現(xiàn)其強(qiáng)大功能。一個(gè)請求中的嵌套字段太多會(huì)導(dǎo)致系統(tǒng)過載。因此，對于復(fù)雜的查詢，REST 仍然是更好的選擇。

緩存復(fù)雜度 。由于 GraphQL 不再使用 HTTP 緩存語義，因此使用者需要額外自定義緩存。

大量的預(yù)開發(fā)教育 。由于沒有足夠的時(shí)間來了解 GraphQL 的某個(gè)操作和 SDL，因此許多項(xiàng)目決定采用眾所周知的 REST 方法。

GraphQL 的用例

移動(dòng) API 。在這種情況下，網(wǎng)絡(luò)性能和單個(gè)消息有效負(fù)載優(yōu)化很重要。因此，GraphQL 為移動(dòng)設(shè)備提供了更有效的數(shù)據(jù)加載方式。

復(fù)雜的系統(tǒng)和微服務(wù) 。GraphQL 能夠隱藏其 API 背后的多個(gè)系統(tǒng)集成的復(fù)雜性。GraphQL 從多個(gè)地方聚合數(shù)據(jù)，并將它們合并為一個(gè)全局的模式。對于隨時(shí)間推移而逐漸擴(kuò)展的遺留基礎(chǔ)架構(gòu)或第三方 API 來說，這尤其重要。

5. 哪種 API 模式最適用你的用例？

每個(gè) API 項(xiàng)目都有不同的限制和需求。通常，API 架構(gòu)的選擇取決于：

• 所使用的編程語言，
• 你的開發(fā)環(huán)境，以及
• 你的資源預(yù)算，包括人力資源和財(cái)務(wù)資源。

在了解了每種設(shè)計(jì)風(fēng)格的利與弊之后，API 設(shè)計(jì)人員可以選擇最適合項(xiàng)目的那一種。

具有強(qiáng)耦合性的 RPC 很適用于內(nèi)部微服務(wù)，但它對外部 API 或者 API 服務(wù)而言不是一個(gè)好的選擇。

SOAP 的使用有些麻煩，但它強(qiáng)大的安全拓展使它在計(jì)費(fèi)操作、預(yù)訂系統(tǒng)和支付方面是無可替代的。

REST 是針對 API 的最高級別的抽象和最佳模型。但它往往會(huì)有些“啰嗦”而增加系統(tǒng)的負(fù)擔(dān) —— 如果你使用的是移動(dòng)設(shè)備，這是個(gè)問題。

GraphQL 在數(shù)據(jù)獲取方面向前邁出了一大步，但并不是每個(gè)人都有足夠的時(shí)間后精力來掌握它。

歸根結(jié)底，去針對一些小型的用例來嘗試某種特定 API 架構(gòu)，并去了解它是否適合你的用例以及是否解決了你的問題，這樣做是比較合適的。如果它適用于你的用例，就可以嘗試擴(kuò)展并查看它是否適用于更多的用例。

原文鏈接：

https://levelup.gitconnected.com/comparing-api-architectural-styles-soap-vs-rest-vs-graphql-vs-rpc-84a3720adefa

程序汪資料鏈接
程序汪接的7個(gè)私活都在這里，經(jīng)驗(yàn)整理
Java項(xiàng)目分享  最新整理全集，找項(xiàng)目不累啦 04版
堪稱神級的Spring Boot手冊，從基礎(chǔ)入門到實(shí)戰(zhàn)進(jìn)階
臥槽！字節(jié)跳動(dòng)《算法中文手冊》火了，完整版 PDF 開放下載！
臥槽！阿里大佬總結(jié)的《圖解Java》火了，完整版PDF開放下載！
字節(jié)跳動(dòng)總結(jié)的設(shè)計(jì)模式 PDF 火了，完整版開放下載！
歡迎添加程序汪個(gè)人微信 itwang007  進(jìn)粉絲群或圍觀朋友圈