段勇賓
公司的規定不一定就是對的。
GET和POST的最大區別有兩個：1、GET是冪等的；2、GET在規範上是不帶BODY的，而URL querystring是有長度限制的。根據不同的特性，應用場景不同。
根據我的理解，一般限制調用都是POST，是API服務端開發者為了統一參數解析的方便。
如果遵守RESTful的好處是，很多網絡和軟硬件基礎設施會根據不同類型請求作出相應的優化。比較常見的是，冪等請求會做緩存優化。
技術規範總是標準化和實用性的權衡，沒有絕對的對錯。
延伸開去，所謂的世俗道德標準，佛教的條條框框也都是如此。因為絕大部分人並不能深刻理解所有東西，這時候就需要一些指導實踐的規矩規範。
一邊理解一邊遵守是對待規範的應有的態度。
正宗烏龜魚
每種請求方式都有它存在的理由！只用post不過是那家公司的人為了省事罷了
笨瓜1號
如果請求類型是text，GET和POST完全相同，不同點是在HTTP包的位置上，GET位於HTTP HEADER中，POST在BODY中。
因為GET是在header中，傳送數據的長度有限制，而BODY是可以分片的，傳送的數據長度就沒有限制了。
如果是作為普通的接口協議，用GET更方便。
有人認為POST比GET安全性好，不存在的，兩者都是明文傳送，如果數據本身不加密，抓個包就看出來了。提高安全性的手段有兩個：1、傳輸協議用https。2、對數據加校驗和鑑權防止偽造。
光明右使8787
前面很多觀點，基本上正確，我補充幾個如果在get上帶參數遇到過的問題，大家可以作為參考，以下觀點不考慮在https已經加密的情況下討論。
無論get或者是body，都是明文傳輸，有人提到protobuf，自定義字節流協議等，這種是屬於傳輸的協議，明文的意思是可以捉取到你傳輸的內容。這種屬於數據傳輸中包體的協議部分，參考Content-Type說明。
1. 如果參數全在url上，很容易被中間的路由所記錄，比如你正在登錄，但帳號以及密碼就放在url裡，哪天中間路由的日誌被爬走了，你的登錄信息就洩露了。
但body就不會被記錄，並不是不能被記錄，但body一般大很多，而且還有圖片文件等字節流，一般是不會被記錄下來的。
參考：tomcat的access日誌，nginx的access日誌，路由日誌等
2. 每個瀏覽器限制的url長度並不是固定的，當超過一定長度時，每個用戶得到的結果就有可能不一致。例如：有可能chrome沒問題，ie或firefox就報錯，作為後臺是不願意看到這種情況的，使用Post就可以很好的避免
3. 每個中間轉發層header的大小也是不一定的，比如nginx有個參數large_client_header_buffers，如果超過了，就會得到一個錯誤：error code 414: uri too large。而且中間轉發層可能不止一個，沒必要踩這種坑對吧。
4. get請求很容易被瀏覽器進行緩存，導致你需要增加一個隨機參數避免緩存命中。
5. 某些網關還會緩存get請求，目的是減少網關交叉訪問時的費用，這種情況更不好控制。
所以規定只能POST可以很大程度規避一些坑，每次把給每個人說清楚還是比較困難的，但做成規定，可以很大程度上避免重複遇到問題。
而當你真的需要用上緩存時，例如前端資源js、css、頁面加載等，就用get把，目的是希望各層都能緩存，加快資源加載速度。
紫夜追風者
我司的API框架就是所有接口都是POST提交的。這樣做理由有以下幾點：
1. 接口調用參數統一，便於開發SDK。
2. 便於傳輸數組和字典類型參數
3. 便於巡檢機器巡檢API服務器是否正常
4. 傳輸參數長度可以足夠長
5. 有利於統一H5、後臺、App、小程序接口，且SDK一致
web架構師自我修煉
[哈欠]個人感覺不是很好！post倒是可以避免get的參數過程，參數暴露等缺陷，但出現就有其出現的道理，restful風格一直是我追隨的！不過主要看公司使用場景！
華夏紫穹
\n
{!-- PGC_VIDEO:{"thumb_height": 360, "thumb_url": "2beed00073a222a64bcac\
倩倩的成長日記vlog
統一後減少出錯概率；避免結果被緩存問題；避免url接口長度限制；調試更方便跟蹤數據，不存在url轉義的問題
瓶子的光芒
因為你們公司水平有問題 post攜帶內容多 get速度快壓力小 post用來提交表單什麼的 get用來做簡單參數請求什麼的 其他其實沒啥區別
星空倒影988
Post和get區別不大 第一點區別服務器緩存 第二點冪等性 第三點也是最大的區別 設計目的不同
