RESTFUL如何指導WEB API設計？

　　博主剛剛接觸web開發的時候，寫了一個接口 /get_article_info/1 獲取id爲1的這篇文章的內容，被前輩們看見了，前輩給我說我這個接口設計的不太好啊，不符合RESTFUL規範，當前輩們說出這些話的時候，我很迷惑，我寫的接口不可以好好工做嗎？可以正常返回內容啊，對於不存在的文章也可以在返回的內容體中提示不存在，並且接口的意思很明確，一看就能明白，這還有什麼很差的地方嗎？

1、RESTFUL是什麼？

　　RESTFUL是英文單詞Representational State Transfer的縮寫，翻譯成中文就是表現層狀態轉化，什麼是表現層？什麼是狀態？什麼是轉化？

　　表現層能夠理解爲一種資源，能夠是一篇文章，一張圖片，一個訂單...... 全部網絡上的一個實體，均可以說是一個資源，在HTTP協議中，URL就是這種資源的表示。狀態和轉化應當連在一塊兒理解，這是一個動做，即狀態變化，好比新建一篇文章，狀態變化是這篇文章從無到有，還有一些其餘狀態變化，更新，刪除，獲取等，那在HTTP協議中如何表示這種變化呢？恰好HTTP協議中有一些請求方法，能夠和這些操做對應上，GET表示獲取，POST表示新建，DELETE表示刪除，PUT表示更新。

　　這樣，將HTTP協議的請求方法和URL組合在一塊兒，就能表示對哪一個資源進行何種操做，這樣的風格就是RESTFUL。

2、 RESTFUL如何指導咱們設計API？

核心思想就是HTTP動詞 + URL資源，好比獲取文章信息 GET /articles, GET是動詞，/articles 是名詞

1. 動詞一般是HTTP的方法

GET：    獲取信息
POST：   新建信息
DELETE： 刪除信息
PUT：    更新信息

2. 資源必須是名詞

已經有了HTTP的方法的動詞，URL中，咱們就沒有必要使用動詞了

POST /create_articles   
POST /delete_articles   
POST /update_articles   

上面都是很差的用法，咱們應當使用下面這種用法

POST    /articles
DELETE  /articles/2
PUT     /articles/2

3. 資源最好使用名詞的複數，任何狀況下都可以適用

/airticles/1  獲取id爲1的文章內容
/airticles    獲取全部文章內容

# 使用單數
/article  獲取一篇文章內容？仍是全部的文章內容？

4. 避免多級URL

/authors/5/airticles  獲取做者id爲5的全部文章

上面換成這種形式更好，也利於擴展
/airticles?author_id=5

5. 利用querystring來過濾和篩選

通常狀況下一個url很難知足複雜多變的狀況，好比分頁，過濾，這時候咱們應當如何設計？

/airticles/published  這種形式？

不不不，published不是一個資源，並且這種url不宜於擴展

最佳實踐應當是下面這種形式

/articles?page=1          獲取第一頁的文章
/articles?published=true  獲取已經發布的文章

6. 返回有意義的狀態碼

HTTP有不少狀態碼，表示不一樣的意義，咱們應當充分利用這些狀態碼

尤爲是出現錯誤時，不要返回200，意義很不明確

通常成功請求後返回的狀態碼

GET：200 OK
POST：201 Created
PUT：200 OK
DELETE：204 No Content

其餘狀態碼信息

1xx：相關信息

2xx：請求成功

3xx：重定向

4xx：客戶端錯誤

5xx：服務器端錯誤

2xx狀態碼錶示成功

200 OK 請求成功

201 Created 請求成功，並建立了資源

202 Accepted 請求接受，但未處理完成，通常用於異步處理

204 No Content 請求處理成功，但未返回內容，通常用於DELETE請求成功

3xx狀態碼錶示重定向

301 Moved Permanently 永久重定向

302 Found 暫時重定向

4xx狀態碼錶示客戶端錯誤

400 Bad Request 錯誤請求，服務器不理解請求，沒作任何處理

401 Unauthorized 未認證

403 Forbidden 用戶經過了認證，可是沒有權限

404 Not Found 沒有發現請求的內容

405 Method Not Allowed 不容許的請求方法

5xx狀態碼錶示服務端錯誤

500 Internal Server Error 服務器內部錯誤，沒法完成請求

503 Service Unavailable 服務不可用

3、總結

　　RESTFUL就是一種規範，咱們不遵循這種規範也可以寫出可用的代碼，可是遵循這種規範卻能給咱們帶來更多的好處，API設計更加可讀，與其餘人交流也可以很方便。如今讓我看看我剛剛接觸web接口開發時的設計，真的是不太好啊，URL信息過重複，錯誤的返回狀態不明確，全是200。

參考文章：https://blog.florimond.dev/restful-api-design-13-best-practices-to-make-your-users-happy