。net 怎么開發(fā)微博 在哪里可以找到源代碼參考？
時間：2023-11-27 23:48:01 | 來源：網(wǎng)站運營
時間：2023-11-27 23:48:01 來源：網(wǎng)站運營
。net 怎么開發(fā)微博 在哪里可以找到源代碼參考？：
1前言
最近電腦壞了，開源項目的進(jìn)度也受到一些影響
這篇醞釀很久了，作為本系列第二部分（API接口開發(fā)）的第一篇，得想一個好的開頭，想著想著就鴿了好久，索性不扯那么多了，直接開寫吧~
2關(guān)于RESTFul
網(wǎng)上很多相關(guān)的文章都要把RESTFul歷史來龍去脈給復(fù)制一遍，所以我這就不重復(fù)了，現(xiàn)在主要的HTTP接口風(fēng)格就倆：RPC和RESTFul。
舉個例子就可以看出這倆的區(qū)別
臨時加更干貨分享大家能看到這里，已是對我們的支持了。
分享一組9月錄制的C#零基礎(chǔ)教程。我們喜歡做這樣的分享，它足夠的基礎(chǔ)，對新手友好。如果需要的話，就來免費領(lǐng)取吧！
快來領(lǐng)取吧資料免費自?。?/h3>由于內(nèi)容過多不便呈現(xiàn)，需要視頻教程和配套源碼的小伙伴，點擊下方卡片！
也可點擊下方卡片：點擊后自動復(fù)制威芯號，并跳轉(zhuǎn)到威芯。搜索威芯號添加，內(nèi)容已做打包，備注本站
即可免費領(lǐng)取，注意查收！
RPC風(fēng)格
分別是增刪改查的接口
| 操作 | HTTP方法 | URL |
|---|
| 增 | post | /blog/add |
| 刪 | post | /blog/deleteById |
| 改 | post | /blog/updateById |
| 查 | get | /blog/getAll |
可以看出RPC風(fēng)格的特點：
- 基本就是用post和get這倆方法來操作接口
- URL的命名跟函數(shù)命名一樣，都是動詞，一目了然
PS：RPC這種幾乎一個團(tuán)隊一個風(fēng)格，我見過有人把所有接口都做成post方法，然后請求參數(shù)全部用json格式放在body里的。
關(guān)鍵是這個請求參數(shù)還不統(tǒng)一，同個項目不同開發(fā)人員寫的請求參數(shù)格式不一致，很惡心。（微信有些接口也是這樣）
RESTFul風(fēng)格
分別是增刪改查的接口
| 操作 | HTTP方法 | URL |
|---|
| 增 | post | /blog/ |
| 刪 | delete | /blog/{id}/ |
| 改 | put | /blog/{id}/ |
| 查 | get | /blog/ |
| 查 | get | /blog/{id}/ |
可以看出RESTFul風(fēng)格的特點：
- 利用各種HTTP方法來實現(xiàn)增刪改查（其實還有patch、head這些方法，不展開了）
- URL的命名是名詞，以資源名稱作為URL，更統(tǒng)一
- 使用get獲取資源，方便后端、客戶端、網(wǎng)關(guān)這些地方做緩存，提高性能
接口返回值
除了請求接口，RESTFul還建議接口返回的時候根據(jù)不同狀態(tài)使用不同的HTTP狀態(tài)碼。
以下是HTTP定義的五類狀態(tài)碼。
| 類別 | 描述 |
|---|
| 1xx：信息 | 通信傳輸協(xié)議級信息。 |
| 2xx：成功 | 表示客戶端的請求已成功接受。 |
| 3xx：重定向 | 表示客戶端必須執(zhí)行一些其他操作才能完成其請求。 |
| 4xx：客戶端錯誤 | 此類錯誤狀態(tài)代碼指向客戶端。 |
| 5xx：服務(wù)器錯誤 | 服務(wù)器負(fù)責(zé)這些錯誤狀態(tài)代碼。 |
- 比如添加了數(shù)據(jù)，返回 201 (created)
- 添加、更新、刪除這些不需要返回數(shù)據(jù)的接口，返回 204 (no content)
- 沒登錄，返回 401 (unauthorized)
- 找不到，返回 404 (not found)
- 沒權(quán)限，返回 403 (forbidden)
這樣就很清晰了，看接口返回的狀態(tài)碼就能知道結(jié)果如何。
在一些前端ajax庫（比如axios）中，返回碼如果是4xx或5xx，就會拋出異常，這樣訪問邏輯就可以根據(jù)錯誤做出一些提示。
例子
假設(shè)接口返回結(jié)構(gòu)是這樣
{ "successful": true, "message": "請求成功", "data": [{...}, {...}, {...}]}請求接口的 JavaScript 代碼如下
axios.get('/blog/') .then(res => msg.success(`請求成功，返回信息：${res.data.message}`)) .catch(res => msg.error(`請求失敗，返回信息：${res.data.message}`))但是！實際場景很復(fù)雜，HTTP標(biāo)準(zhǔn)狀態(tài)碼就40個，根本不夠用啊。
所以這些HTTP狀態(tài)碼只能對返回值做個大概的分類，復(fù)雜系統(tǒng)還是得自己定義一套錯誤碼。
小結(jié)
這倆各有優(yōu)劣，RESTFul看起來比較統(tǒng)一優(yōu)雅，但表達(dá)能力有限；RPC的URL命名看起來比較隨意，不過自由發(fā)揮的空間也很大。
我個人是比較傾向RESTFul風(fēng)格的，所以StarBlog使用了RESTFul風(fēng)格的接口，不過這并不能滿足全部功能需求，所以參考Django的RestFramework，將RESTFul和RPC稍微結(jié)合一下。
舉個例子：要在博客增刪改查的基礎(chǔ)上增加設(shè)置置頂、點贊等功能。
| 操作 | HTTP方法 | URL |
|---|
| 設(shè)置置頂 | post | /blog/{id}/setTop/ |
| 點贊 | post | /blog/{id}/thumbUp/ |
| 獲取置頂文章 | get | /blog/getTop/ |
可以看到這種縫合怪是以RESTFul為基礎(chǔ)，增刪改查以外的功能，在對應(yīng)的資源上使用RPC風(fēng)格。
setTop /
thumbUp /
getTop 這些動詞在RestFramework里面也叫 action ，意為對一系列資源執(zhí)行的動作。
關(guān)于HTTP方法，對資源有修改的，使用post方法，沒有修改單純讀取的，使用get方法。
3接口開發(fā)規(guī)劃
本系列文章更新順序跟StarBlog博客開發(fā)的順序基本一致，即在已有MVC架構(gòu)網(wǎng)站的基礎(chǔ)上，增加RESTFul接口，用于管理后臺（前后端分離）對博客進(jìn)行配置管理。
目前我把接口分成這幾類
- auth - 認(rèn)證授權(quán)，顧名思義，后面會細(xì)說
- admin - 管理員相關(guān)，主要功能有配置管理、訪問記錄、系統(tǒng)監(jiān)控等
- blog - 博客相關(guān)，功能就是文章、分類、圖片等信息的crud
- common - 公用接口，StarBlog除了博客功能外，還以接口形式提供了一些小功能，如一句詩、一言、隨機(jī)圖片、主題切換等
- test - 測試接口，用于一些功能測試，在正式環(huán)境會關(guān)閉訪問
- links - 友情鏈接管理，這個功能比較復(fù)雜，單獨做成一個分類
后續(xù)會有更多類似友情鏈接這樣比較復(fù)雜的功能加入（比如評論），這種會單獨做成一個分類。
PS：之前在開發(fā)博客前臺的時候，把大部分功能都寫在了 services 里面，現(xiàn)在開發(fā)接口的時候就派上用場了，很多邏輯都是通用的，在接口的controller里面只需要調(diào)用這些 services 就可以了。
4需要關(guān)注的其他東西
本文不涉及具體實現(xiàn)，只是作為RESTFul接口開發(fā)部分的前言或者大綱，接口開發(fā)看似就crud四個操作很簡單，實際上比想象的復(fù)雜。
例如，獲取文章列表接口，博客的文章數(shù)量會很多，不可能一個接口返回所有文章信息，因此要做分頁處理，同時我們還希望能在文章列表實現(xiàn)關(guān)鍵詞過濾、分類、狀態(tài)篩選、排序等功能；
已登錄用戶才能發(fā)表評論，管理員才能管理文章，因此需要實現(xiàn)認(rèn)證授權(quán)、角色管理等功能；
同一時間可能有很多人訪問博客（或者是爬蟲），需要對接口做限流處理，以免程序崩潰；
接口數(shù)量多起來了，swagger顯示太雜亂，需要對接口分組，或者更換swagger前端；
正式環(huán)境不想讓用戶看到swagger接口文檔，可以隱藏或者給swagger加鎖；
頻繁訪問的資源，可以使用服務(wù)端緩存提升性能，減輕IO壓力，使用客戶端緩存降低服務(wù)器流量；
耗時操作（如批量導(dǎo)出文章、發(fā)送短信通知）放到異步任務(wù)隊列（或者后臺任務(wù)）里執(zhí)行；
以上列舉的種種只是我在撰寫本文的當(dāng)下考慮博客需要用到的，實際上應(yīng)該還有很多。只能說后端的水很深，開發(fā)本項目的過程也是一個不斷探索、實踐的過程，“No silver bullet”，沒有任何技術(shù)能適用全部場景，只能在不斷的積累中得出某個場景下的最佳實踐。
OK，本文就到這吧。
原文鏈接：基于.NetCore開發(fā)博客項目 StarBlog - (21) 開始開發(fā)RESTFul接。
在線咨詢
