facebook、谷歌、github、netflix 和幾個其他的科技巨頭已經允許開發者和其產品通過 api 呼叫他們的資料，並為他們提供平台。即使你不是寫 api 的專業人士，擁有精美的 api 也對你的應用程式有好處。
關於設計 api 的最好方法，網路上有較長一段時間的爭論，但官方也沒有對此給出解釋。
api 是乙個介面，通過它許多開發者可與資料互動。 設計優良的 api 使用起來很方便，並給開發者的工作帶來便利。 api 是開發者的 gui，如果它設計不合理，開發者會將它替換。所以，開發者的經驗是衡量 api 質量的最重要的指標。
--api就像乙個在舞台上表演的藝術家，其使用者就是其觀眾
以下是與 rest api 相關的重要術語：
為了更好理解，我們給公司寫 api，這些公司都有一些員工。/getallemployees 是對員工列表進行回應的 api。公司其他 api 大致如下:
並且將有大量的和這些操作不同的 api 端點，它們包含大量冗餘的行為。因此，當 api 數量增加時，這些 api 端點將很難維護。
**不對？
每個 url 代表一種資源（resource），所以 url 中只能有名詞，不能有動詞。 api 路徑 /addnewemployee 包含了操作 addnew 和資源名稱 employee。
那麼怎樣算是正確的方式？
/companies 是乙個很好的不包含操作的例子。但是問題來了，我們該怎樣告訴伺服器我們要進行的操作呢？新增，刪除，還是更新？
這時 http 方法（get，post，delete，put）（也稱為動詞）就可以起到作用了。
資源在 api 端點中應該總是複數，如果我們想訪問資源的乙個例項，我們可以傳遞 url 中的 id。
在其他的一些使用案例中，如果我們有一些資源在某個資源之下，例如，乙個公司的員工，那麼在這樣的例子中 api 的 endpoint（端點） 就應該是這樣的：
現在這樣，api 是不是更嚴謹和一致了呢？
結論：路徑應該包含資源的複數形式，http 方法應該定義成各種行為在資源上執行。
http 定義了幾組方法，這些方法給出了對資源要執行的操作型別。
--url 是乙個句子，其中資源是名詞，http 方法是動詞。
主要的http方法如下：
get 方法從資源請求資料，不產生多餘結果。
例如： /companies/3/employees 會返回公司3的所有雇員列表。
post 方法請求伺服器在資料庫中建立資源，這主要用於提交 web 表單時。
例如： /companies/3/employees 建立乙個公司3的新雇員。
post 是非冪等的，這意味著多個請求將會有不同的效果。
put 方法請求伺服器更新資源或建立資源（如果不存在的話）。
例如： /companies/3/employees/john 將請求伺服器在公司3的雇員集合中更新或在不存在的情況下建立關於 john 的資源。
put 是冪等的，這意味著多次請求具有相同的效果。
delete 方法將請求的資源或例項從資料庫中刪除。
例如： /companies/3/employees/john/ 將請求伺服器從公司3的雇員集中刪除 john 資源。
http 中還有很多其他方法，我們將在另一篇文章中討論。
當客戶端通過 api 向伺服器發起請求時，無論請求是失敗的、通過的還是錯誤的，客戶端應該獲得反饋。http 狀態碼是一堆標準化的數值碼，在不同的情況下具有不同的解釋。伺服器應始終返回正確的狀態碼。
以下是 http 狀態碼的主要分類：
2xx (成功類別)
這些狀態**表示請求的操作已被伺服器接收到並成功處理。
delete算是其中乙個很好的例子。
api delete /companies/43/employees/2 將刪除員工 2，作為響應，我們不需要在該 api 的響應正文中的任何資料，因為我們明確地要求系統將其刪除。如果有任何錯誤發生，例如，如果員工 2 在資料庫中不存在，那麼響應碼將不是 2xx 對應的成功類別，而是 4xx 客戶端錯誤類別。
3xx (重定向類別)
4xx (客戶端錯誤類別)
這些狀態**表示客戶端發起了錯誤的請求。
5xx（伺服器錯誤類別）
您可以遵循任何套管約定，但要確保其在應用程式中一致。如果請求主體或響應型別是json，那麼請按照camelcase(駝峰命名法)來保持一致。
這些行為都只是針對乙個資料集進行的查詢。由於還沒有一套新的 api 來處理這些行為。因此，我們需要向 get 方法的 api 附加查詢引數。
我們來理解幾個例子看它們是如何實現這些行為的。
如果在 get 方法中附加了很多查詢引數，會造成 uri 太長，伺服器可能會響應 414 的 http 狀態，表示這個 uri 太長，在這種情況下，我們也可以將引數傳遞給 post 方法的請求體中。
當你的 api 被開始被廣泛使用後，突然公升級api會打破現有的產品、服務。
是乙個很好的例子，它的路徑中有api的版本號。如果有任何重大的中斷更新，我們可以將新的api集命名為v2或v1.x.x
這些指南是根據我的開發經驗編寫的。我很想知道你對上述幾點的看法。
RESTful API 設計指南
網路應用程式，分為前端和後端兩個部分。當前的發展趨勢，就是前端裝置層出不窮 手機 平板 桌面電腦 其他專用裝置 因此，必須有一種統一的機制，方便不同的前端裝置與後端進行通訊。這導致api構架的流行，甚至出現 api first 的設計思想。restful api是目前比較成熟的一套網際網路應用程式的...
RESTful API 設計指南
網路應用程式，分為前端和後端兩個部分。當前的發展趨勢，就是前端裝置層出不窮 手機 平板 桌面電腦 其他專用裝置.因此，必須有一種統一的機制，方便不同的前端裝置與後端進行通訊。這導致api構架的流行，甚至出現 api first 的設計思想。restful api是目前比較成熟的一套網際網路應用程式的...
RESTful API 設計指南
原文 網路應用程式，分為前端和後端兩個部分。當前的發展趨勢，就是前端裝置層出不窮 手機 平板 桌面電腦 其他專用裝置.因此，必須有一種統一的機制，方便不同的前端裝置與後端進行通訊。這導致 api 構架的流行，甚至出現 api first 的設計思想。restful api 是目前比較成熟的一套網際網...