喝咖啡休息#31。每個開發人員都應該避免的 9 個職業錯誤。為什麼 REST API 架構越來越受歡迎？

每個軟體開發人員都應該避免的 9 個職業錯誤

資料來源：Infoworld 說實話。你們中的一些人開始學習程式設計是因為你或你的父母認為這樣更容易賺很多錢。你在學校時並不真正喜歡計算機，也不真正喜歡軟體開發。如果這是真的，那麼這意味著你將永遠是一個平庸的程式設計師。是的，您會賺到很多錢，因為我們的行業青睞它，但本文不適合您。但是，如果你小時候因為拆開電子產品來弄清楚它們是如何工作的而受到懲罰......如果你花了半個晚上在互聯網上學習如何創建視頻遊戲......如果你花了寶貴的空閒時間學習什麼沒有人問過你...這篇文章是寫給你的。你需要改變對職業的看法。你寫程式不再是為了好玩：你是為了錢。為了好玩，您可以支持您的個人專案。但請確保您至少喜歡您的日常工作。如果沒有，請盡可能尋找更好的地方。你的目標應該是開設你的退休基金，把你所有的稅後錢存進去，買房子，買車，做你想做的事。也許旅行。同時，你需要考慮你的職業生涯，而不僅僅是你目前的工作。為此，您需要避免九個陷阱，我們現在將討論這些陷阱。

陷阱#1：不要在一種技術上停留太久

我明白。您喜歡 C#、Java、JavaScript、Python 還是 Cobol。但大多數技術都有採用、高峰、外包、利基和過時的生命週期。我的意思是，如果你在 20 世紀 80 年代認識 Cobol，那就太酷了。但現在 Cobol 程式設計師賺的錢不多。也就是說，重點是，只知道一種程式語言，遲早你將不得不削減開支，搬到更便宜的城市，因為你的收入會減少。

陷阱二：不要成為 IT 壟斷者

您需要對沖您的投資。看起來您只需要成為當前主導市場的技術的專家。但隨後你將面臨許多競爭。此外，當您的專業需求下降時，您應該已經制定了退出計劃。例如，當Java問世時，我是一個C++極客。我學了Java。幾年前，每個人都開始談論 Ruby 作為程式語言中的新星。在某個時候，Perl 似乎將達到與 Java 相同的水平。預測未來是困難的，因此對沖你的賭注是確保就業市場相關性的最安全方法。

陷阱#3：不要緊抓時尚

魔法遲早會消失。人們不會僱用 Groovy 或 Ruby 開發人員。如果你的老闆允許你在專案中使用遺留語言，那要不是因為他不在乎，就是只是無知。無論如何，學習和使用最新的技術。準備好成為第一個了解它們的人並成為這方面的專家。另一方面，如果您的專業需求下降，也要準備好做出重大改變。總有其他新技術值得愛上，無論是語言還是資料庫。

陷阱#4：對規則過敏

每個組織，無論大小，都有自己的辦公室規則。你必須研究它們並遵循它們。否則，你就會成為別人遊戲中的棋子，或是發現自己在團隊中被孤立。如果您對職業生涯和工作中富有成效的關係感興趣，請學習遵循辦公室規則中的 防禦策略。

陷阱#5：對商業不感興趣

“我只是一個開發者，我對商業不感興趣。” 這是一條沒有出路的路。你需要學會數數。你的公司經營得好嗎？其主要業務目標為何？她最重要的項目是什麼？科技或軟體如何幫助實現這些目標？貴公司如何適應整個產業？如果你不知道這些問題的答案，你最終就會在不重要的公司為不重要的人做不重要的項目，而得到的錢卻相對微不足道。

迷思六：「工會團結」心態

當我年輕的時候，我的一位同事是一位幾乎提前六個月就計劃好一切的人。他犯了一個錯誤，去度假了，所以我在兩週內完成了整個項目，但給他留了一件工作。我以為他會為此感到高興。原來他並不高興。這一切都以他利用一切機會解僱我而告終。這成了他的主要目標。他甚至向我們的新主管抱怨我。當然，我做了所有的工作。我是一個創新者。我總是在尋找新的方法來更好更快地做事並解決問題。我離開去另一份工作後不久他就退休了。有幾次我在咖啡館見到他，我們假裝不認識。這不是我最後一次遇到這種類型的工作：「慢慢地做事，否則事情會變得更糟。」我的建議：編寫正確的程式碼，但要為意外情況做好準備。如果問題無法解決，請摔門而去：您的公司不是市場上唯一的公司。

陷阱七：你不知道自己的價值

“我來這裡不是為了錢。” 那麼，培養一個愛好吧。不要每天上班都想著下一份薪水。如果你的收入比其他人低 50%，你也不應該去工作。了解你的價值，不要低估它。

陷阱＃8：把你的工作當作一份工作

“這只是一份工作。” 不，這是你職業生涯的一步。你不會永遠從事這份工作。那你在這裡能學到什麼？您的下一步計劃是什麼？你最終想要去哪裡？這項工作將如何幫助您實現這一目標？提高您對周圍環境的認識。從長遠來看，這將對您有好處。這不僅是一份工作，更是一段旅程。

陷阱九：你認為這只是錢的問題

銷售人員喜歡說：“如果你擲硬幣，我就工作。” 是的，但是除非你從事銷售工作，否則沒有人願意與僅僅為了錢而從事該工作的人一起工作。我知道我只想與對自己的工作負責的人一起工作。你呢？另一方面，也沒有必要承擔難以承受的責任。如果您真正擔心的是關於標籤或間隙的永恆爭論，您可能需要服用鎮靜劑。

為什麼 REST API 架構越來越受歡迎？

資料來源：DZone 即時通訊是一件了不起的事。我們都習慣了可以與世界任何地方即時通訊。透過桌上型電腦或行動設備，我們可以隨時隨地購買、發布、附加和選擇任何東西。我們彼此之間以及與世界之間的連結是前所未有的。但這是怎麼發生的呢？數據如何「從那裡」到達我們？ 設備和應用程式使用應用程式介面（API）相互通訊。這正是「引擎蓋下」的引擎。它總是在幕後，我們傾向於將其視為普通的東西，但正是 API 創造了我們所依賴的所有互動性。

什麼是 API？

簡單來說，API 就是一個信使，它接受請求，告訴系統你想要做什麼，然後回傳回應給你。舉一個直覺的例子，將 API 想像成餐廳裡的服務生。想像一下，您坐在桌旁，手裡拿著菜單，廚房是準備您訂單的系統的一部分。API 是將您的訂單傳輸到廚房並將食物送到餐桌的連結。

讓我們舉一個真實的例子：

我們都熟悉在線搜索航班的過程，並且知道為了預訂航班，我們必須與航空公司的網站互動。您可以存取他們的資料庫，查看特定日期是否有空位，以及根據您的航班要求預計的費用。但是，如果您不使用可直接存取資訊的航空公司網站怎麼辦？如果您使用從不同航空公司收集資訊的線上預訂服務怎麼辦？該服務與航空公司的 API 進行交互，其中 API 是一個接口，就像我們樂於助人的服務員一樣，從在線服務請求有關座位預訂以及乘客選擇的餐食或行李偏好的信息。然後，API 獲取航空公司的回應並將其傳回線上服務，後者向乘客顯示資訊。所有其他應用程式、資料和裝置之間都會發生大致相同的過程。它們都有 API，允許電腦控制它們，這最終創建了通訊。

有哪些類型的 API？

API架構可以透過兩種主要方式實現：其中一種實現資訊傳輸的方式是SOAP，另一種主要方式是REST。我們已經確定 API 可提供兩個應用程式之間的通訊。現在我們將了解 SOAP 和 REST 如何精確地融入通訊架構。

SOAP應用程式介面

SOAP（簡單物件存取協定）是一種 Web 服務，遵循在稱為 W3C 的中央機構和一組核心規範之間建立的具有某些通訊原則的規範。該套裝包括：

• 肥皂
• WSDL
• UDDI

SOAP 是定義兩個應用程式如何相互通訊的協定。兩個應用程式在相互溝通時必須遵循共同的格式，而這種共同的格式必須基於XML語言。SOAP API 中的 XML 必須符合 SOAP Message 標準，該標準由 Envelop、Header 和 Body 組成。

休息API

這是一個非常重要但經常被誤解的 Web 服務概念，因此讓我們來解讀一下 REST 或 RESTful API 的意思。REST 是一種 Web 服務，它使用自己的架構原則在兩個應用程式之間發起通訊。REST架構是一種不遵循任何協定的架構風格，沒有嚴格的規範，也沒有控制規範的中央機構。這使得 REST 能夠靈活地使用或建立任何類型的服務。當建立 Web 服務時應用這些原則時，我們就得到了 RESTful Web 服務。現在讓我們更深入地了解 REST 架構所基於的原則。

統一介面

在 RESTful 架構中，一切都可以被視為資源。例如，如果您嘗試為員工管理系統建立應用程式。該應用程式可以使用任何語言在任何平台上針對任何平台進行開發。同樣，任何資料庫都可以用來處理內部服務。REST API 中資源的概念意味著使用者可以將任何資訊或任何模組定義為資源。給定一個員工管理系統，創建者可以定義員工資源、部門以及應用程式中使用的任何其他模組。

無國籍

在 RESTful 架構中，所有回應和請求以及伺服器之間的所有通訊都是無狀態的。這意味著伺服器不維護系統的當前狀態，客戶端可以發送自己完成的請求。而這個請求不依賴之前的任何請求。例如，如果您正在線上購物並將商品新增至購物車，伺服器將不會維護您的購物車的狀態，因此每次使用者向伺服器提交請求時，它將包含當時的購物車狀態已提出請求。當無狀態時，伺服器沒有儲存或維護會話的開銷，因此提高了 Web 服務的效能。

快取能力

在上一個協定中，我們注意到在 RESTful 架構中，伺服器不保存會話狀態，所有快取都發生在客戶端。每當客戶端向伺服器發送請求時，伺服器都會傳回一個回應，其中包含實際資料以及其他元數據，告訴客戶端是否應該在本地儲存回應。

多層次系統

REST 原則規定，每當客戶端和伺服器之間進行通訊時，它們之間就可以存在多個層，並且這些層可用於實現多種目的，例如訊息轉換、效能增強、快取和各種其他功能。每個層級的通訊都有特定的任務。透過多層通信，系統可以有效地運行，從而提高速度和耐用性。

根據要求提供代碼

這是 RESTful Web 服務的一個可選限制，在使用者提交請求以接收回應時起作用。響應可以運行客戶端程式碼。這項原則擴展了通訊的功能。

為什麼 REST API 的使用越來越頻繁？

REST 在很大程度上更容易使用、更靈活，並且與 SOAP 相比具有許多優點。例如，您不需要昂貴的工具即可與任何 Web 服務互動。REST架構更簡單，可以輕鬆定制，並且在創建通訊模型時不需要特殊技能。使用起來效率很高，因為它可以利用伺服器的客戶端來儲存客戶端相關的資訊。REST 使用更小的訊息格式並提供更快的交互，因為它不需要耗時的處理。在設計理念方面，REST 也更接近其他 Web 技術。

SOAP 還是 REST？

對於典型 Web 應用程式的需求，SOAP 通常是多餘的。REST 是一個更簡單的解決方案，當 Web 應用程式需要 API 時，它擁有您所需的一切。然而，有時 API 需要稍微複雜一點才能完成任務。例如，如果自動請求需要 API，那麼 SOAP API 將是該場景的更好選擇。簡而言之，如果問題龐大且複雜，則選擇 SOAP；如果需要簡單的解決方案，則選擇 REST。