鑽石舞台

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

在受疫情影響被迫中斷兩年後，2022 年的巴菲特午餐於當地時間 6 月 12 日 19 時 30 分（北京時間 13 日 7 時 30 分）在 eBay 開拍，持續到 6 月 17 日結束，起拍價為 2.5 萬美元（約 16.85 萬元人民幣）。

今日上午，2022 年巴菲特慈善午餐拍賣落幕，歷時五天 43 次出價，最終成交價為 1900 萬美元（約 1.27 億元人民幣），此次成交價刷新曆屆紀錄。網站上參與拍賣用戶的真實身份不予披露，只顯示加密賬號。

IT之家了解到，勝出者可最多邀請 7 人與巴菲特一起在紐約市的史密斯與沃倫斯基（Smith & Wollensky）牛排館共進午餐，午餐會上可以向巴菲特提出各種問題，但唯一不能談論的話題是問巴菲特接下來可能會買什麼。

現年 91 歲的巴菲特通過於 2000 年開始的午餐拍賣活動為格萊德基金會籌集了超過 3420 萬美元（約 2.24 億元人民幣），自 2008 年以來，每次中標者出價都超過 100 萬美元。據格萊德基金會介紹，2022 年將是最後一屆巴菲特慈善午餐拍賣活動。

特別提醒

有網友表示收不到IT之家公眾號的推送，這是因為現在微信規則改版了，請將「IT之家」公眾號星標，並記得給文章點讚和在看，這樣文章推送時系統才會優先推送給你。

(繼續閱讀...)

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

（給ImportNew加星標，提高Java技能）

REST

REST(REpresentational State Transfer）是 Roy Fielding 博士於 2000 年在他的博士論文中提出來的一種軟件架構風格(一組架構約束條件和原則)。在該論文的 中文譯本 中翻譯是"表述性狀態移交"。

原則

網絡上的所有事物都被抽象為資源

每個資源都有一個唯一的資源標識符

同一個資源具有多種表現形式(xml，json 等)

對資源的各種操作不會改變資源標識符

所有的操作都是無狀態的

資源（Resources）

資源是一種信息實體或者說是一個具體信息，能夠被想象出名字。比如多個圖書館，那麼便是可使用的圖書館資源，而圖書館內，多個樓層，那麼便擁有了多個樓層的資源，各樓層提供了不同服務，那麼服務也是資源。在互聯網中，可以用一個 URI（統一資源定位符）指向它，每種資源對應一個特定的 URI（如同一本書，按照書頁碼去定位哪一頁，目的是定位資源）。訪問這個特定 URI 便獲取到了這個對應的資源。

表述（REpresentations）

資源的表述是一段對於資源在某個特定時刻的狀態的描述，通過表述捕獲資源，並在組件間(客戶/服務器)移交該表述。表述有多種格式，如 HTML/XML/JSON/純文本/圖片/視頻/音頻等。具體的表述格式，可以在 HTTP 請求頭信息中用 Accept 和 Content-Type 字段指定，請求/響應方向的表述通常使用不同的格式。

狀態移交（State Transfer）

對於組件間而言(客戶/服務器)，資源的請求是一個互動過程。通過表述捕獲資源當前或是預期的狀態，相當於獲得了資源的狀態。通過移交代表資源的表述，來將資源在組件的兩者之間進行傳遞，進而改變應用狀態。如當客戶端獲取了資源後，自身狀態處於穩定，當再次獲取資源後自身狀態再次處於穩定。客戶端操作並對服務端發起請求，在資源上執行各種動作而打破資源自身狀態，達到客戶端操作所期望狀態。

RESTful Api

與 REST 相比多了一個 ful，就英語層面來說是一個形容詞，RESTful 翻譯成中文為「REST 式的」，滿足了 REST 架構風格的應用程序設計的 Api 則便是 RESTful Api，即 REST 式的 Api。

以往 Api 設計

在 MVC 項目中，經常都是設計成動賓結構給 ajax 調用

/getCustomers/getCustomersByName/getCustomersByPhone/getNewCustomers/verifyCredit/saveCustomer/updateCustomer/deleteCustomer

可有時卻因為沒有統一的規範，多人協作時，對於動詞的描述上也沒有統一，時長出現了類似如下的各類叫法，不能說這種情況有什麼弊端，畢竟這種方式也是正常工作着。

/getCustomers/getAllCustomer/getCustomerList/getPagedCustomer/queryCustomers/queryAllCustomers/queryCustomerList...

相比之下，RESTful Api 提供了更為標準化，規範化的 URL 寫法。

設計規範

考慮 Api 設計時，URI 中不能有動詞，URI 的目的是定位資源，而具體的對資源的操作，是藉助 HTTP 的動詞完成，與早期 Api 設計相比，本身的思路是不同的，原來更多的是考慮函數式編程或者叫做面向行為的服務建模，比如 RPC，遠程調用一個函數，那麼 Api 設計便是會考慮為動詞名詞格式，而對於 REST 風格來講，是面向資源的服務建模。而對於資源而言，可以是對象、數據或是查詢服務。

HTTP 動詞

對於一個系統而言，對外提供的功能總體上劃分為兩類：

獲取系統資源，主要包括讀取資源和資源描述信息。

對系統資源進行變更，主要包括寫入資源，對已有資源狀態的變更，刪除已有資源。

對於這其中使用到的一些動詞，使用 HTTP 的動詞描述來承擔對資源執行的行為，動詞通常使用以下幾種。對於 HTTP1.1 規範中的其他幾個動詞（如 OPTIONS 等）則不再介紹。

GET: 獲取目標資源。

HEAD: 獲取（傳輸）目標資源的元數據信息。該方法與 GET 相同，但是不傳遞內容體。

POST: 創建新資源，對於複雜查詢而言，提交查詢表單給查詢服務也是常用 POST 的（當然其他幾個能做的它也能做）。

PUT: 替換已有資源(整體)。

PATCH: 修改已有資源(局部)。

DELETE: 刪除資源。

URI

URI 作為統一資源標識符，其本質是標識資源，就像進入圖書館，任一本書都應具有在哪個樓層，哪個區域，哪個書架等等標識信息，來唯一確定這本書，於資源而言，更是如此，對於 URI 的設計，規範是使用名詞來定位資源，比如常見的

GET/Api/Users/{id}

這樣便按照 id 值，來唯一定位這一 User

(繼續閱讀...)

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()

鑽石舞台 發表在 痞客邦 留言(0) 人氣()