什麼是restful？
restful是在2023年由roy thomas fielding博士在他的博士**中提出。
他是http 1.0和1.1版本協議的主要設計者，apache**會的第一任主席，可以說是現代網際網路體系的奠基者。
fielding將他對網際網路軟體的架構原則，定名為rest，即表述層狀態轉移（representational state transfer）。
這是一套在網際網路體系下，呼叫者如何與被呼叫者（資源實體）進行互動的規範設計。
restful有什麼樣的規範？
在restful理論中，乙個uri位址，指向乙個資源物件
設計
以不同的請求方式，來實現資源物件的不同操作。
get ：從伺服器取出資源（一項或多項）
post ：在伺服器新建乙個資源
put ：在伺服器更新資源（客戶端提供改變後的完整資源）
patch ：在伺服器更新資源（客戶端提供改變的屬性）
delete ：從伺服器刪除資源
例如：
有乙個資源物件為user，1 是資源物件中的某乙個物件中的唯一標識id。
get /user：返回所有使用者物件的列表（陣列）
get /user/resource：返回單個使用者物件
post /user：返回新生成的使用者物件
put /user/resource：返回完整的使用者物件
patch /user/resource：返回完整的使用者物件
delete /user/resource：返回乙個空文件
複數url
既然 url 是名詞，那麼應該使用複數，還是單數？
這沒有統一的規定，但是常見的操作是讀取乙個集合，比如get /articles（讀取所有文章），這裡明顯應該是複數。
為了統一起見，建議都使用複數 url，比如get /articles/2要好於get /article/2。
避免多級url
常見的情況是，資源需要多級分類，因此很容易寫出多級的 url，比如獲取某個作者的某一類文章。
get /authors/12/categories/2
這種 url 不利於擴充套件，語義也不明確，往往要想一會，才能明白含義。
更好的做法是，除了第一級，其他級別都用查詢字串表達。
get /authors/12?categories=2
下面是另乙個例子，查詢已發布的文章。你可能會設計成下面的 url。
get /articles/published
查詢字串的寫法明顯更好。
get /articles?published=true
狀態碼
狀態碼必須精確
客戶端的每一次請求，伺服器都必須給出回應。回應包括 http 狀態碼和資料兩部分。
http 狀態碼就是乙個三位數，分成五個類別。
這五大類總共包含100多種狀態碼，覆蓋了絕大部分可能遇到的情況。
每一種狀態碼都有標準的（或者約定的）解釋，客戶端只需檢視狀態碼，就可以判斷出發生了什麼情況，
所以伺服器應該返回盡可能精確的狀態碼。
api 不需要1xx狀態碼。
狀態碼詳情可以看常見http狀態碼
伺服器響應
不要返回純本文
api 返回的資料格式，不應該是純文字，而應該是乙個 json 物件，因為這樣才能返回標準的結構化資料。
發生錯誤時，不要返回 200 狀態碼
有一種不恰當的做法是，即使發生錯誤，也返回200狀態碼，把錯誤資訊放在資料體裡面，就像下面這樣。
}上面**中，解析資料體以後，才能得知操作失敗。
這張做法實際上取消了狀態碼，這是完全不可取的。
正確的做法是，狀態碼反映發生的錯誤，具體的錯誤資訊放在資料體裡面返回。下面是乙個例子。
}提供鏈結
api 的使用者未必知道，url 是怎麼設計的。
這樣的話，使用者只要記住乙個 url，就可以發現其他的 url。這種方法叫做 hateoas。
舉例來說，github 的 api 都在 api.github.com 這個網域名稱。訪問它，就可以得到其他 url。
","gists_url": "",
"hub_url": "",
...}
上面的回應中，挑乙個 url 訪問，又可以得到別的 url。
對於使用者來說，不需要記住 url 設計，只要從 api.github.com 一步步查詢就可以了。
hateoas 的格式沒有統一規定，上面例子中，github 將它們與其他屬性放在一起。
更好的做法應該是，將相關鏈結與其他屬性分開。
,]}}
restful介面規範
資源 resource 任何東西都是一種資源，例如，一篇部落格文章 表示 representation 資源的一種表現形式，例如，json xml url 每個資源都應該有乙個對應的url uri url是uri的一種，url都有對應的資源，而uri不一定，它強調的是一種資源標識 get 獲得乙個資...
restful介面規範
聯絡兩個物質的媒介，完成資訊互動 web程式中 聯絡前台頁面與後台資料庫的媒介 web介面組成 請求引數 前台按照指定的key提供資料給後台 響應資料 後台與資料庫互動後將資料反饋給前台 狀態碼,狀態資訊,響應資料 web資料請求介面設計規範共10條,可以分為url與響應兩部分 url 響應部分 f...
Restful介面規範
2000年roy fielding博士在其博士 中提出rest representational state transfer 風格的軟體架構模式後，rest就基本上迅速取代了複雜而笨重的soap，成為web api的標準了。restful作為目前最流行的 api 設計規範，一定有著它獨有的魅力 強...