restful是目前最流行的 api 規範，適用於 web 介面規範的設計。讓介面易讀，且含義清晰。本文將介紹如何設計易於理解和使用的 api，並且借助 docker api 的實踐說明。
它的核心思想就是客戶端發出的資料操作指令都是「動詞 + 賓語」的結構，比如 get /articles這個命令，get是動詞，/articles是賓語。
動詞通常來說就是五種 http 方法，對應我們業務介面的 crud 操作。而賓語就是我們要操作的資源，可以理解成面向資源設計。我們所關注的資料就是資源。
正確的例子
有些客戶端只能使用get和post這兩種方法。伺服器必須接受 post 模擬其他三個方法（put、patch、delete）。
這時，客戶端發出的 http 請求，要加上x-http-method-override屬性，告訴伺服器應該使用哪乙個動詞，覆蓋 post 方法。
就是 api 的url ，是 http 動詞作用的物件，所以應該是名詞。例如 /books 這個 url 就是正確的，而下面的 url 不是名詞，都是錯誤的寫法。
錯誤示範：
get /getallusers?name=jl
post /createuser
post /deleteuser
沒有統一的規定，但是我們通常操作的資料多數是乙個集合，比如get /books,所以我們就使用複數。
統一規範，建議都使用複數 url， 比如 獲取 id = 2 的書get /books/2要好於get /book/2。
有時候我們要操作的資源可能是有多個層級，因此很容易寫多級 url，比如獲取某個作者某種分類的文章。
get /authors/2/categories/2 獲取作者id = 2 分類 = 2 的文章
更好的方式就是 除了第一級，其他級別都是通過查詢字串表達。
正確方式：get /authors/12?categories=2
查詢已發布的文章
錯誤 寫法： get /artichels/published
正確寫法： get /artichels?published=true下面是一些常見的引數。 引數的設計允許存在冗餘，即允許api路徑和url引數偶爾有重複。比如，get /zoo/id/animals 與 get /animals?zoo-id=id 的含義是相同的。推薦後者，避免出現多級url。
客戶端的請求，服務求都必須響應，包含 http 狀態碼和資料。
http 狀態碼就是乙個三位數，分成五個類別。
200狀態碼表示操作成功，但是不同的方法可以返回更精確的狀態碼。
4xx狀態碼表示客戶端錯誤，主要有下面幾種。
5xx狀態碼表示服務端錯誤。一般來說，api 不會向使用者透露伺服器的詳細資訊，所以只要兩個狀態碼就夠了。
有一種不恰當的做法是，即使發生錯誤，也返回200狀態碼，把錯誤資訊放在資料體裡面，就像下面這樣。
錯誤例子：
上面**中，解析資料體以後，才能得知操作失敗。
這張做法實際上取消了狀態碼，這是完全不可取的。正確的做法是，狀態碼反映發生的錯誤，具體的錯誤資訊放在資料體裡面返回。下面是乙個例子。
正確方式：
接下來我們分析 docker api 對於 restful 的使用，助於我們在實際工作中合理設計。
docker 文件 url ：
通過 all=1&before=8dfafdbc3a40&size=1 過濾容器資料
假如想過濾程序等可以通過查詢字串實現
返回的資料
根據容器 id 刪除乙個容器，v是請求是否刪除 容器 volumes
Restful最佳實踐
restful 是目前最流行的 api 設計規範，用於 web 資料介面的設計。它的大原則容易把握，但是細節不容易做對。本文總結 restful 的設計細節，介紹如何設計出易於理解和使用的 api。restful 的核心思想就是，客戶端發出的資料操作指令都是 動詞 賓語 的結構。比如，get art...
RESTful介面設計原則 最佳實踐（學習筆記）
restful介面設計原則 最佳實踐 學習筆記 1 restful介面建議統一使用複數，而不是單數 2 不建議使用hateoas 3 在大多數的教案中，都推薦使用accept header來指明是xml還是son，而作者建議直接在url中增加.json或者.xml 4 使用snake case命名風...
最佳實踐 Flutter 最佳實踐
最佳實踐是乙個領域可以接受的專業標準，對於任何程式語言來說，提高 質量 可讀性 可維護性和健壯性都非常重要。讓我們探索一些設計和開發flutter應用程式的最佳實踐。class enum typedef和extension應採用駝峰命名uppercamelcase規則。class mainscree...