get與post的請(qǐng)求一些區(qū)別

目錄

背景

get 與 post 的區(qū)別

所有接口都用 post 請(qǐng)求？

背景

最近在逛知乎的時(shí)候發(fā)現(xiàn)一個(gè)有趣的問題：公司規(guī)定所有接口都用 post 請(qǐng)求，這是為什么？

看到這個(gè)問題的時(shí)候其實(shí)我也挺有感觸的，因?yàn)槲乙苍?jīng)這樣問過我自己。在上上一家公司的時(shí)候接到一個(gè)項(xiàng)目是從零開始搭建一個(gè)微服務(wù)，當(dāng)時(shí)就有了解過接口的一些規(guī)范，比如耳熟能詳?shù)?Restful 規(guī)范，就被應(yīng)用到這個(gè)微服務(wù)項(xiàng)目中。

get 與 post 的區(qū)別

今天再次看到這個(gè)問題，我也有了一些新的理解和感觸，臨時(shí)回顧了一下 get 與 post 的請(qǐng)求的一些區(qū)別。

如下：

post 更安全（不會(huì)作為 url 的一部分，不會(huì)被緩存、保存在服務(wù)器日志、以及瀏覽器瀏覽記錄中）

post 發(fā)送的數(shù)據(jù)更大（get 有 url 長(zhǎng)度限制）

post 能發(fā)送更多的數(shù)據(jù)類型（get 只能發(fā)送 ASCII 字符）

post 比 get 慢

post 用于修改和寫入數(shù)據(jù)，get 一般用于搜索排序和篩選之類的操作

get 請(qǐng)求的是靜態(tài)資源，則會(huì)緩存，如果是數(shù)據(jù)，則不會(huì)緩存

查看上面的區(qū)別，就會(huì)發(fā)現(xiàn) post 在發(fā)送數(shù)據(jù)量大的請(qǐng)求時(shí)優(yōu)勢(shì)很顯示，get 則更適合獲取靜態(tài)資源、簡(jiǎn)單的查詢等接口。

我個(gè)人在開發(fā)接口的時(shí)候也會(huì)注意，將簡(jiǎn)單的查詢請(qǐng)求使用 get 方法，其他增、刪、改、復(fù)雜的查詢請(qǐng)求都可以使用 post，但不會(huì)像題主的公司一樣全部使用 post。

所有接口都用 post 請(qǐng)求？

| 網(wǎng)友程墨 Morgan

網(wǎng)友程墨 Morgan 提出如果是自己會(huì)按照『業(yè)界最佳實(shí)踐』制定規(guī)范：

| 網(wǎng)友蘇莉安

另外一個(gè)知友提出：就是為了遷就低水平不思進(jìn)取的架構(gòu)師和前后端程序員們。

| 網(wǎng)友大寬寬

大寬寬的回答：我打算跳出技術(shù)的范疇，從 ROI 的角度討論下如果一個(gè)架構(gòu)風(fēng)格（比如 Restful）真的那么好，為啥應(yīng)用上沒有那么廣泛？ 首先要明確，不管你多么喜歡技術(shù)，無論是這里說的一個(gè) http 的 method，又或者是編程語言的一些用法、架構(gòu)設(shè)計(jì)方法、甚至是 OKR 這樣的管理和溝通的方法。這一切，都是為了滿足企業(yè)對(duì)市場(chǎng)的需求。 簡(jiǎn)單來說，公司給你發(fā)工資，不是為了讓你遵守規(guī)范的，而是為了能在成本可接受的情況下，讓業(yè)務(wù)落地。而其中，一般情況下，接口的形式是個(gè)微不足道的局部問題。 對(duì)于企業(yè)來講，技術(shù)團(tuán)隊(duì)要解決的更重要的問題：

是理解業(yè)務(wù)模型，形成業(yè)務(wù)架構(gòu)和可以穩(wěn)定跑的系統(tǒng)；

是面對(duì)大量涌入用戶對(duì)系統(tǒng)可用性的要求對(duì)系統(tǒng)不會(huì)卡頓掛機(jī)的擴(kuò)展性保障；

是不會(huì)動(dòng)不動(dòng)抽瘋一下，丟條數(shù)據(jù)或者數(shù)據(jù)沖突的穩(wěn)定性要求，以及為了達(dá)成這些要求給監(jiān)控體系的各種便利。

但一定要糾結(jié)下 POST/GET，以及 Restful。好吧，Restful 能明確列出來的好處，就那么幾點(diǎn)（如果有疏漏的請(qǐng)?jiān)谠u(píng)論區(qū)里補(bǔ)充）。 如下：

表達(dá)不同的業(yè)務(wù)動(dòng)作語義：GET/POST/PATCH/PUT/DELETE……，

表達(dá)“資源”的概念利用

url path，querystring，header，status code 等來表達(dá)很多接口功能

以上兩條可以達(dá)成一種“統(tǒng)一”的接口表達(dá)形式，以至于可以圍繞這個(gè)形式實(shí)現(xiàn)接口維護(hù)的工具，比如 swagger。

Get 資源可以利用緩存

但代價(jià)是什么？ ①強(qiáng)行的統(tǒng)一，讓本來天然不是資源的業(yè)務(wù)概念也一定要強(qiáng)行“資源“一下，引發(fā)了更多的理解不一致和溝通困難。 當(dāng)然，事物總是和可以“抽象”一下，業(yè)務(wù)概念抽象為“資源”很多時(shí)候都是可行的。但這這么做的收益除了證明“一個(gè)人聰明，有不錯(cuò)的抽象能力“，以及“更容易利用上 swagger 一類的工具“之外，我看不到啥額外的短期或者長(zhǎng)期收益。 ②亂折騰 path，querysting 等東西，讓橫切面治理抓取關(guān)鍵信息更難了。比如監(jiān)控時(shí)抓一個(gè) path 里帶變量的 url 是非常惡心的事情。 又或者看到一個(gè) 404 的報(bào)警，卻根本搞不清楚到底是服務(wù)部署有問題；還是服務(wù)正常，但用戶不存在；又或者是用戶存在，但用戶訂單不存在。帶來的問題是運(yùn)營(yíng)工具編寫困難，線上問題響應(yīng)能力會(huì)被降低。 ③即使使用 swagger，還是需要寫說明和文檔來說明其業(yè)務(wù)語義。接口工具應(yīng)該提供的“好理解，接口改了后文檔自動(dòng)生成”等好處，只有在接口反應(yīng)的資源剛好和后臺(tái)數(shù)據(jù)表/視圖能夠?qū)?yīng)上才有效。 也就是說只適合接口層級(jí)低的場(chǎng)景下有用，而對(duì)高層接口意義不大。結(jié)果開發(fā)者既要用 swagger 這樣的工具，同時(shí)還是要看常規(guī)文檔。本來用一套機(jī)制可以解決的問題要改成兩套。 ④Cache 雖好，但最怕的是管控不到位讓用戶拿到了過期數(shù)據(jù)。對(duì)于 Cache，業(yè)務(wù)上一般會(huì)區(qū)分動(dòng)態(tài)接口和靜態(tài)接口。 前者默認(rèn)不應(yīng)該有 cache，所以用了 Get 之后為了防范，還得手工在大部分動(dòng)態(tài)接口上加 Cache-Control: no-cache，或者動(dòng)態(tài)產(chǎn)生 ETag（浪費(fèi) CPU）。而后者一般會(huì)采用 CDN，這一套針對(duì) cache 做了很精巧的設(shè)計(jì)。 ⑤使用形式各異的 method 和 url path，querystring 上做各種奇怪的拼接，會(huì)給前端帶來巨大的困擾。 因?yàn)楸緛硪粋€(gè)函數(shù)調(diào)用，還得翻譯一遍，活生生的弄出來一個(gè)接口翻譯層。妥妥的降低人效。如果是 web，iOS，Android 三套前端，就得弄 3 個(gè)接口翻譯層。 ⑥非 GET 和 POST 之外的 method 有可能會(huì)被不恰當(dāng)?shù)木W(wǎng)關(guān)轉(zhuǎn)發(fā)規(guī)則給干掉。為此 Restful 還是搞出了 method override 這樣的招數(shù)…… 所以到底適不適合，落地時(shí)聽罵聲和吵架聲就知道了。 有人舉了 Google S3 運(yùn)用 Restful 接口的例子來說明其正確性。但 S3 是干什么的大家都懂，S3 天然就是用來存取“資源“的。 一個(gè)工具用在了恰當(dāng)場(chǎng)景，當(dāng)然是“正確“的。S3 用的好的東西，只能說明類似的阿里云 OSS，騰訊云 COS 也可以這么干。但無法證明電商業(yè)務(wù)、社交業(yè)務(wù)、I 醫(yī)療業(yè)務(wù)、政企辦公協(xié)同……這些業(yè)務(wù)也適合這么干。 而作為技術(shù)負(fù)責(zé)人，如果他搞出了一套接口方案（也許其中一條就是所有 http 接口都用 post），提高了開發(fā)效率，降低了溝通成本，降低了運(yùn)維和錯(cuò)誤定位成本，為企業(yè)真正做到了降本增效。 把瞎折騰的成本，投入到了其他比如業(yè)務(wù)架構(gòu)設(shè)計(jì)，測(cè)試體系，線上監(jiān)控，容災(zāi)降級(jí)等領(lǐng)域上。 最終讓企業(yè)（用戶需求得到滿足，收入增加）和員工得到了收益（因?yàn)楣臼杖朐黾佣鴿q薪）。 我會(huì)評(píng)價(jià)這樣的人為“真正懂架構(gòu)，懂技術(shù)，善于用技術(shù)解決實(shí)際問題。水平不知道高到哪里去了”。 如果一個(gè)技術(shù)負(fù)責(zé)人只知道遵守一個(gè)書上寫的，但從沒驗(yàn)證過在自己的環(huán)境有效的方案，以至于讓企業(yè)的核心目標(biāo)無法達(dá)成。他就是趙括，該馬上卷鋪蓋卷走人。 至于我司，使用的規(guī)范是：對(duì)于動(dòng)態(tài)業(yè)務(wù)接口，只有一個(gè)接口 POST/action，在 Header 里給 X-Action 給出具體的接口名稱交給網(wǎng)關(guān)路由，session 表示用戶登錄身份，以及用于推薦、防重、染色、安全用到的各種 token/簽名。 所有的業(yè)務(wù)請(qǐng)求參數(shù)都以 PB 編碼后放在請(qǐng)求體里，并和后端的 gRPC 體系銜接。接口除了防重試之外，不提供常規(guī)意義上的 Cache。 而對(duì)于靜態(tài)接口，走 CDN，做多級(jí) Cache。該用 Get 用 Get。如果一個(gè)動(dòng)態(tài)接口也想利用 http 層 Cache，可以向網(wǎng)關(guān)申請(qǐng)和配置。有沒有 Cache，cache 多久是網(wǎng)關(guān)和端上自己實(shí)施的，完全自己管控。 各位讀者可以參考看看，并根據(jù)自己所處的業(yè)務(wù)場(chǎng)景和前后端交互思考下“我們目前用的技術(shù)規(guī)范是性價(jià)比最高的嗎，是最合適的嗎？“ 如果是你來設(shè)計(jì)公司的 API 規(guī)范，會(huì)規(guī)定所有接口都用 post 請(qǐng)求嗎，這是為什么？