開放的api是個好東西:
從google,facebook,twitter 到國內的各種sns,微博站點, 它們中的絕大部分都有一套基於http＋xml/json的開放api。靠這些開放api, 乙個簡單的手機客戶端也能做很多事情，如果配合自己的伺服器程式, 開發者很快就可以推出一套低成本的客戶端＋網路服務。首先感謝這些開發api提供者, 不過我也想想說說我的看法:
先憶苦思甜，和早期的webservice， soap xml 這些重型http api比較，現在主流的解決方案:http＋json，已經是非常輕便好用了. 不知道還有沒有人記得拿jbuilder自動生成webservice**的的時候, 我想只有靠**行數拿工資的程式設計師才會懷念那些日子。
但是，現在的開放api還是有不少改進的空間， 我至少遇到了一些問題:
第乙個問題：沒有區分第三方客戶端和伺服器兩個完全不同的環境。比如認證登入這塊，採用oauth是為了不讓第三方站點獲取到使用者密碼, 通過web介面登入再跳轉. 對第三方web伺服器是合適的。但是對客戶端，我覺得這樣是多此一舉。使用webview容易丟失焦點， 介面loading延遲， 而且也無法真正防止惡意客戶端偷偷獲取賬號/密碼。 這樣的結果是什麼呢？ 最好的客戶端都是不用oauth的直接走特殊認證的。 如果乙個api設計的結果是第三方要靠繞過它顯示自己技術或者商務談判或者使用者體驗牛逼。 那麼可以認為這個api的適用範圍需要調整了。
第二個問題是， api的往往是按照服務自身邏輯完整性設計的， 而不是按照使用案例設計的， 乙個糟糕的例子如下，顯示最近朋友的更新，需要先獲取朋友列表id， 然後獲取每個朋友個人資訊， 然後獲取每個朋友產生的文字內容。 這不是呼叫3次api的問題， 這是呼叫1+2/*n次api的問題。
第三個問題: 客戶端**跑後台執行緒是受限的, 很多api給出的資源都是單獨的url。 如果很多零零碎碎的小需要同螢幕顯示，而手機又存在手機和wifi兩種速度差別很大的網路，客戶端需要大量的**來處理非同步讀取和錯誤處理(請考慮可能還有幾個**api要同時支援). 而且這段**維護起來也很痛苦. (這個時候在server寫乙個頁面, 然後在客戶端直接用webview顯示是個不錯的辦法)
最後乙個問題: 更新！ 在伺服器上更新， 廢棄乙個api是非常快的事情。 但是客戶端上就慢多了，客戶端不同的版本共存則是常事。 如果開放api做了不相容的修改, 老的客戶端就完全不可用了. 如果你使用了些第三方api的封裝庫而它沒有更新，你會更痛苦。我們的做法是在伺服器有一整套proxy api server， 客戶端盡可能和自己的api打交道， 把對開放api的支援放到server上做，這樣倒是能解決問題。但是我覺得從專業分工的角度上看， 不是每個客戶端團隊都有應該做這樣的事情。
那麼我們該怎麼做呢?
如果是你客戶端開發者, 隔離,封裝是必要的, 如果可能, 盡量把開放api放到server上支援,保持客戶端的簡單. (另外離那些非官方的api封裝包遠遠的！）如果你是伺服器程式設計師, 真心希望你可以嘗試一下客戶端網路程式設計,比如iphone和android. 這樣能幫助你設計出更好的api. 畢竟: 你總需要用用自己設計的東西嘛.
開始管理乙個小團隊
開始管理乙個小團隊，加上我是3個人，我是個team leader，工作職責是確保分公司這邊it系統及服務正常，及一些本地專案的跟進。這對我自己來說是個新的開始，開始帶人。一直以來自己都習慣於自己幹活，習慣了那種簡明高效的方式，現在的話，說實話，要別人幹得跟自己一樣的確有難度。有要求吧，以自己的標準來...
將乙個小應用接入開放平台之一
就人人網來說 1.註冊賬號，成為一名開發者 3.填寫基本資訊，這個按要求填就可以了。4.填寫應用基本資訊設定，這個比較重要 canvas page name 這個要唯一，平台會判斷，這也決定了你的canvas url，canvas url的功能就是應用平台的訪問位址，就是只要訪問這個位址，平台就會知...
微信小程式外部API呼叫方法，遇到的乙個小問題
ajax請求使用這種方式不起作用。改為直接在header中賦值生效了，不知道什麼原因，希望遇到同樣問題的夥伴可以不用彎路。beforesend function xhr 解決方法 header 詳細 如下 confirm function var timestamp new date gettime...