infoq之前的一篇新聞報道了william vambenepe的問題「如果雲計算的先驅者們都不使用rest，它對於雲計算還重要嗎？」報道發表之後，william作出了進一步的反饋，試圖闡明自己最初那篇博文的中心思想，而這中心思想卻被別人忽視了，或者說視而不見。他的本意是：對於開發者而言，拋開語言結構（物件或rpc）底層的互動機制，互動的方法是否通過rest實現並不重要。正如william所言：\ \
如他所指出的，aws使用了一種非常接近xml-rpc的方法。他們在此方法中作出了一些權衡，但是總體來說，aws採取了實用的方法，最終產生了一種概念上簡單卻又強大（並且可用）的方法。然而，很多人似乎仍然不同意這個看法，比如mike pearce提到：
\
我知道我是乙個rest迷（人們這樣稱呼那些對rest痴迷的人）。但是事實上，amazon上並沒有證明任何東西，除了傲慢和不尊重開發者之外，什麼也沒有。\
william試圖在最近的博文中解釋mike所擔心的安歇問題。譬如，其中mike問到：
\
aws使用自己實現的api而不採用標準，比如，哦，我還不知道，rest。對於那些不想學習aws互動方式卻不得不學習的開發者，這難道不是一種折磨麼？\
mike對此非常肯定，而william卻不這麼看……
\
我很疑惑。我看見過很多開發者艱難地理解rest。我卻從未見過哪個開發者被rpc所嚇倒。至於rest是乙個「標準」的說法，我得去看看規範。不要讓我去讀博士**。\
william認為，關鍵的問題不是rest對於雲計算的發展是否重要，而是雲計算是否已經發展到了那個（開發者或實施者）必須（或應該）作出根本性變革的點。william的觀點是，單個提供商產品帶來的rest的優勢是非常有限的。
\
雲api的使用模式可能會發展到那個點，在這個點上遵循rest規則所能帶來的價值是非常誘人的。我只是認為我們還沒有到這個點，而且老實說我也不為此激動。在這個熱議的問題變成雲服務提供商間互動時應考慮的問題之前，雲服務還需要許多功能上的改進。而當共享的restful api成為最簡單的協作api時，共享的rpc api也一定會變得非常容易管理。到那時，最熱的話題可能會變成共享語義的問題，而不再是協議了。\
\
大多數aws（或其他雲**商的）使用者從來看不到api。他們是通過語言包、或web客戶端應用與這些雲服務互動的。所以，真正關心此問題的人是rest迷們，以及庫開發者們（比如我）。也許有那種差勁到人們無法使用的api存在，但是aws query api遠不至於那麼糟糕。它相當統一，而且很容易程式設計。只不過它不是rest。另外，值得一提的是，並非所有aws服務都是這樣的。s3、cloudfront和route53的api都比較傾向於restful。\
william最近博文的整體主題是，好的開發者介面可以隱藏非rest api方法，而且還非常有價值，而反過來（譯註：rest api卻無很好的開發者介面）並不一定是這樣的。好介面與底層rest的結合也許是業界最終將會實現的理想世界，但是在現階段，為了雲的成功，既沒有必要也沒有足夠的條件這麼做。對於雲開發者而言，確保資源語義和程式設計介面（包括錯誤處理）的正確性比最好的restful介面顯得更加重要。
\
如果你的rpc api足夠統一，以至於可使用rest api做其底層模型，那就很好了。\
檢視英文原文：rpc or rest in the cloud?
硝煙又起 Amazon搶奪微軟Azure雲服務使用者
美國時間5月8日，amazon宣布提供一項新的服務，企業使用者可以在amazon的雲服務上使用微軟的資料庫和網路程式設計平台asp.net，意在通過此舉搶奪微軟的使用者。很多人認為，amazon和 azure在雲市場競爭的領域不同。amazon主打iaas 基礎設施即服務 雲服務，而微軟的則是paa...
國內雲計算市場的紛爭
戰況 差距主要是由於時間差。比達諮詢分析師李錦清以為。2009年，阿里5.4億元收購了萬網，在當年這是阿里系最大的一筆投資案，讓阿里雲在短期內獲得了範圍化的企業使用者。也就是在那一年，阿里雲創立。當初的國內企業對雲計算的概念還比較模糊，阿里雲提供的效勞也還在技術層面，更像是搭建基礎設定。最典型的事情...
又拍雲上傳
參照位址 1 前端vue上傳 拖拽上竄 拖拽上傳 export default 監聽屬性 watch 計算屬性 computed mounted 自定義方法 methods ondrop e 上傳又拍雲 upload upyun function files this.axios.post this...