1. 程式人生 > >帶上RESTful的金手銬,你累嗎?

帶上RESTful的金手銬,你累嗎?

是不是 還得 如果 在操作 出錯 你在 客戶 定義 tree命令

  1. 首先RESTful是一套規範,不是框架,它是來約束你的。也不關心生產效率的提高。就好像使用匯編開發應用,性能是快了,但是生產效率很低。RESTful它需要你在路由上定義很多規則來解釋的URL,假如你有1000個接口,你是不是得寫1000個正則表達式來解釋URL,還得管理它不讓它出錯,成本是不是很高?業務代碼都沒有寫,就折騰這些去了。

  2. 在開發的層面上,把這麽多參數堆積在url上,看起來其實不直觀。舉個類比的例子。

   例子1 在linux命令行裏,文件,目錄過長的路徑是不是看起來很頭疼,看都不想看。 你就很想使用tree命令查看結構化的目錄文件

例子2 在寫代碼的函數裏,是不是入參個數超過6個,就開始覺得這個函數看起來很麻煩了?

  url上帶有各種參數,請問如何調試?假如我要批量刪除,如果100個用戶,拼接的url是不是特別長?

以上的問題,都是可以通過程序員的聰明才智在RESTful規範下解決,但是值得你這樣去做嗎?

3. 個人感受,我覺得RESTful是web時代的產物,因為瀏覽器裏面就只能輸入url,他們希望通過url就能實現web的全部功能。但是現在這個時代,就算是網頁web也是要很多響應式的交互,並不是論壇,網頁那種簡單的數據的陳列展示了。

4. RESTful 把各種資源都拆分這麽細,讓客戶端自己分別請求,就好像客戶端在操作數據庫一樣。RESTful api,特別是一些開放平臺,面向不定的客戶端,它無法知道它的使用者到底要如何使用它,所以它為了靈活性就相當於把數據庫的操作能力轉了一下給了客戶端 。可是app最好不要請求這麽多接口,最好一次請求返回整個頁面的數據。‘


所以使用RESTful ,你考慮一下生產效率,維護成本,調試方便,有沒有做成開發平臺的必要性?

帶上RESTful的金手銬,你累嗎?