我爲何反對RESTful

我反對RESTful

並非說RESTful徹底錯誤，只是不同意它的理念。

我的觀點，不喜勿噴！學識有限，淺談輒止！

首先，看個小程序。對於下面這個類，咱們如今指望pid只讀。

class User
{
    private String name;//姓名
    private String pid;//身份證號
    ...

    public User(String newName,String newPid)
    {
        name = newName;
        pid = newPid;
    }
}

方法一：增長getter

public String getPid()
{
    return pid;
}

方法二：同時增長getter/setter

public void setPid(String newPid)
{
    throw new Exception("Sorry!不讓改！");
}
public String getPid()
{
    return pid;
}

不知你們採用哪一種？？

再舉個例子，若是你有一間房子，你永遠不打算從南面走出去。那麼，你是在南邊裝扇門並永遠鎖上，仍是乾脆不在南牆上裝門？

其實我想說的是————對於一個系統（或乾脆就指一臺服務器）而言，對外提供的應該是‘通過包裝的有限服務’，而不能把全部資源全盤托出，讓使用者自選操做。

HTTP做爲網絡協議，它的設計目標是處理靜態資源（從最先的純html頁面，到後來普遍支持各類文件），隨着web應用的需求愈來愈複雜，出現了動態網站，而動態資源仍然是由應用服務器生成靜態資源經HTTP協議轉發的。

原來的web服務器，直接基於OS和文件系統操做靜態資源，於是使用GET/POST/DELETE/PUT來表示對資源的操做；而應用服務器，至關於前端邏輯與數據資源的中間件，對資源的處理是應用程序的工做，CRUD是接口內部實現中考慮的問題，應當保持在應用程序內部。

接口的設計應只考慮當前業務功能是什麼（報名/下單/改簽/..），一項具體的業務需求是一個短語或一句話，深層次已經包含了目標資源和對應操做，請求業務時無需再額外描述「增刪改查」的概念。因爲系統服務的包裝性，資源不可直接外露，因此API中URI的實際做用應該是USI（Uniform Service Identifier）。

####RESTful的問題就在於，它是面向資源的，而不是面向服務的。

• 最現實的問題就是————對於任一個URI，開發者都要判斷HttpMethod，對於不支持的動做都要返回一個405或自定義消息。這，難道不是一件很無聊的事情麼？
• 最重要的問題仍是————上面說到的，系統應該嚴格控制對內部資源的訪問，以服務的方式對外提供訪問接口，主動屏蔽不支持的操做，而不是遇到不支持的操做再報錯。

誠然，RESTful只是一種風格，並無改變程序功能。是否使用RESTful，最終實現的邏輯可能徹底一致；但從系統設計角度看，形式化的東西也很重要。

###————————————————————

退一步講，姑且不說上面的問題，RESTful自己也是先天不足的————由於HTTP在web應用方面是先天不足的，而且HTTP的設計比較簡單，其報頭主要用於描述HTTP通訊參數和狀態，而RESTful使用HTTP動詞和狀態碼來表示業務邏輯，沒法避免語義衝突和表達能力弱的問題。

衝突是由於：前端收到的狀態碼，多是HTTP協議直接返回的，也多是應用邏輯返回的。咱們作過一個項目，經理要求必須用HTTP狀態表示業務請求結果。我極力反對，但不被採納。結果：404被用來表示「您查詢的××不存在」，而Server宕機或接口不匹配時，APP收到的結果也是這個；405/407/410直接被HttpURLConnection拋IOException。 而且標準狀態碼那麼少，遇到複雜些的項目，也不夠用啊。固然，能夠自定義狀態碼，可是業務邏輯侵入網絡協議毫不是一個好辦法。仍是使用自定義Header或自定義消息格式靠譜，雖然使用頭部字段也觸碰了HTTP協議，但自定義頭原本就是留給應用做擴展的，並不會干擾協議工做）

還看到有人提出RESTful最好實現Hypermedia API（http://my.oschina.net/u/2337119/blog/532450） ————這也不是一個好點子。一個系統應當嚴控業務接口的開放程度，API應提早綁定在遠端。若是「你」不知道「我」這裏有哪些服務可用，那麼「你」就不該該來訪問「我」，由於這樣的「你」應該不是一個正常的訪問者，不然，「你」應當知道系統服務列表，並確切地知道每一項業務對應的具體API。上文中和github的API做比較，是錯誤的。Github是開放平臺，原本就是面向開發者、方便開發者的，API自己就是開發者須要查詢的信息，需另當別論。

可能有人會說，API的調用者實際上是系統框架內的遠端APP、頁面或軟件，RESTful使用HTTPS能夠實現安全通訊，至關於這樣的API是工做在系統內部，資源直接可見不成問題。對此，我也是反對的。曾經的DES很安全，後來不行了；曾經咱們覺得MD5沒問題，後來也被質疑了；如今SSL也已滴過血了，儘管暫時還算安全，誰知道哪天就掛了......絕對的網絡安全是不存在的；而且SSL實現的是通訊安全，不會保證遠端的應用沒有被綁架。一個可靠的、健壯的系統，不能把自身的安全徹底寄託在第三方身上，必需要以本身爲主，該採起的策略和措施同樣不能少。

---

RESTful的誕生源於：開發人員但願Web service和app開發的基礎架構和部分通用邏輯可以標準化。這個願望並無錯，但我認爲人們在HTTP協議上打算盤倒是錯誤的。這隻能是對上述指望的一次嘗試，一次使用現有工具「將就着」實現理想中新工具功能的嘗試。RESTful可否最終標準化，未來應該會有正式的、完善的新協議來取代RESTful以及HTTP，或許就叫作WASP吧。 [Web Application Service Protocol]