目錄
- 背景
- get 與 post 的區別
- 所有介面都用 post 請求？
背景
最近在逛知乎的時候發現一個有趣的問題：公司規定所有介面都用 post 請求，這是為什麼？
看到這個問題的時候其實我也挺有感觸的，因為我也曾經這樣問過我自己。在上上一家公司的時候接到一個專案是從零開始搭建一個微服務，當時就有了解過介面的一些規範，比如耳熟能詳的 Restful 規範，就被應用到這個微服務專案中。
get 與 post 的區別
今天再次看到這個問題，我也有了一些新的理解和感觸，臨時回顧了一下 get 與 post 的請求的一些區別。
如下：
- post 更安全（不會作為 url 的一部分，不會被快取、儲存在伺服器日誌、以及瀏覽器瀏覽記錄中）
- post 傳送的資料更大（get 有 url 長度限制）
- post 能傳送更多的資料型別（get 只能傳送 ASCII 字元）
- post 比 get 慢
- post 用於修改和寫入資料，get 一般用於搜尋排序和篩選之類的操作
- get 請求的是靜態資源，則會快取，如果是資料，則不會快取
檢視上面的區別，就會發現 post 在傳送資料量大的請求時優勢很明顯，get 則更適合獲取靜態資源、簡單的查詢等介面。
我個人在開發介面的時候也會注意，將簡單的查詢請求使用 get 方法，其他增、刪、改、複雜的查詢請求都可以使用 post，但不會像題主的公司一樣全部使用 post。
所有介面都用 post 請求？
網友程墨 Morgan
網友程墨 Morgan 提出如果是自己會按照『業界最佳實踐』制定規範：
網友蘇莉安
另外一個知友提出：就是為了遷就低水平不思進取的架構師和前後端程式設計師們。
網友大寬寬
大寬寬的回答：我打算跳出技術的範疇，從 ROI 的角度討論下如果一個架構風格（比如 Restful）真的那麼好，為啥應用上沒有那麼廣泛？
首先要明確，不管你多麼喜歡技術，無論是這裡說的一個 http 的 method，又或者是程式語言的一些用法、架構設計方法、甚至是 OKR 這樣的管理和溝通的方法。這一切，都是為了滿足企業對市場的需求。
簡單來說，公司給你發工資，不是為了讓你遵守規範的，而是為了能在成本可接受的情況下，讓業務落地。而其中，一般情況下，介面的形式是個微不足道的區域性問題。
對於企業來講，技術團隊要解決的更重要的問題：
- 是理解業務模型，形成業務架構和可以穩定跑的系統；
- 是面對大量湧入使用者對系統可用性的要求對系統不會卡頓掛機的擴充套件性保障；
- 是不會動不動抽瘋一下，丟條資料或者資料衝突的穩定性要求，以及為了達成這些要求給監控體系的各種便利。
但一定要糾結下 POST/GET，以及 Restful。好吧，Restful 能明確列出來的好處，就那麼幾點（如果有疏漏的請在評論區裡補充）。
如下：
- 表達不同的業務動作語義：GET/POST/PATCH/PUT/DELETE……，
- 表達“資源”的概念利用
- url path，querystring，header，status code 等來表達很多介面功能
- 以上兩條可以達成一種“統一”的介面表達形式，以至於可以圍繞這個形式實現介面維護的工具，比如 swagger。
- Get 資源可以利用快取
但代價是什麼？
①強行的統一，讓本來天然不是資源的業務概念也一定要強行“資源“一下，引發了更多的理解不一致和溝通困難。
當然，事物總是可以“抽象”一下，業務概念抽象為“資源”很多時候都是可行的。但這這麼做的收益除了證明“一個人聰明，有不錯的抽象能力“，以及“更容易利用上 swagger 一類的工具“之外，我看不到啥額外的短期或者長期收益。
②亂折騰 path，querysting 等東西，讓橫切面治理抓取關鍵資訊更難了。 比如監控時抓一個 path 裡帶變數的 url 是非常噁心的事情。
又或者看到一個 404 的報警，卻根本搞不清楚到底是服務部署有問題；還是服務正常，但使用者不存在；又或者是使用者存在，但使用者訂單不存在。帶來的問題是運營工具編寫困難，線上問題響應能力會被降低。
③即使使用 swagger，還是需要寫說明和文件來說明其業務語義。 介面工具應該提供的“好理解，介面改了後文件自動生成”等好處，只有在介面反應的資源剛好和後臺資料表/檢視能夠對應上才有效。
也就是說只適合介面層級低的場景下有用，而對高層介面意義不大。結果開發者既要用 swagger 這樣的工具，同時還是要看常規文件。本來用一套機制可以解決的問題要改成兩套。
④Cache 雖好，但最怕的是管控不到位讓使用者拿到了過期資料。 對於 Cache，業務上一般會區分動態介面和靜態介面。
前者預設不應該有 cache，所以用了 Get 之後為了防範，還得手工在大部分動態介面上加 Cache-Control: no-cache，或者動態產生 ETag（浪費 CPU）。而後者一般會採用 CDN，這一套針對 cache 做了很精巧的設計。
⑤使用形式各異的 method 和 url path，querystring 上做各種奇怪的拼接，會給前端帶來巨大的困擾。
因為本來一個函式呼叫，還得翻譯一遍，活生生的弄出來一個介面翻譯層。妥妥的降低人效。如果是 web，iOS，Android 三套前端，就得弄 3 個介面翻譯層。
⑥非 GET 和 POST 之外的 method 有可能會被不恰當的閘道器轉發規則給幹掉。 為此 Restful 還是搞出了 method override 這樣的招數……
所以到底適不適合，落地時聽罵聲和吵架聲就知道了。
有人舉了 Google S3 運用 Restful 介面的例子來說明其正確性。但 S3 是幹什麼的大家都懂，S3 天然就是用來存取“資源“的。
一個工具用在了恰當場景，當然是“正確“的。S3 用的好的東西，只能說明類似的阿里雲 OSS，騰訊雲 COS 也可以這麼幹。但無法證明電商業務、社交業務、I 醫療業務、政企辦公協同……這些業務也適合這麼幹。
而作為技術負責人，如果他搞出了一套介面方案（也許其中一條就是所有 http 介面都用 post），提高了開發效率，降低了溝通成本，降低了運維和錯誤定位成本，為企業真正做到了降本增效。
把瞎折騰的成本，投入到了其他比如業務架構設計，測試體系，線上監控，容災降級等領域上。
最終讓企業（使用者需求得到滿足，收入增加）和員工得到了收益（因為公司收入增加而漲薪）。
我會評價這樣的人為“真正懂架構，懂技術，善於用技術解決實際問題。水平不知道高到哪裡去了”。
如果一個技術負責人只知道遵守一個書上寫的，但從沒驗證過在自己的環境有效的方案，以至於讓企業的核心目標無法達成。他就是趙括，該馬上捲鋪蓋捲走人。
至於我司，使用的規範是：
對於動態業務介面，只有一個介面 POST/action，在 Header 裡給 X-Action 給出具體的介面名稱交給閘道器路由，session 表示使用者登入身份，以及用於推薦、防重、染色、安全用到的各種 token/簽名。
所有的業務請求引數都以 PB 編碼後放在請求體裡，並和後端的 gRPC 體系銜接。介面除了防重試之外，不提供常規意義上的 Cache。
而對於靜態介面，走 CDN，做多級 Cache。該用 Get 用 Get。如果一個動態介面也想利用 http 層 Cache，可以向閘道器申請和配置。有沒有 Cache，cache 多久是閘道器和端上自己實施的，完全自己管控。
各位讀者可以參考看看，並根據自己所處的業務場景和前後端互動思考下“我們目前用的技術規範是價效比最高的嗎，是最合適的嗎？“
如果是你來設計公司的 API 規範，會規定所有介面都用 post 請求嗎？
