-
1 # 非著名攻城獅
-
2 # 奔十億紅包來
打個比喻:世界上有那麼多的刀，你卻認為家裡的菜刀(get、post)最牛逼，菜刀在手，走遍天下，反正能用，卻不管什麼場景用什麼刀最好用，最方便，好比剪指甲，明明指甲刀更好，而你拿起菜刀照樣幹。。。
-
3 # 網路圈
對於軟體開發行業而言離不開介面（API）的存在，開發人員肯定用過第三方的API也曾自己寫過API給其它人呼叫。就現在而言，API基本上都是Web API形式，而API請求方式以GET和POST居多。但要說介面程式設計只用GET和POST，這種觀點就是錯誤的！
Web API是當前主流的介面形式我們常說的“介面”其實是指應用程式介面，也就是API。API將某種業務功能封裝起來便於第三方呼叫，任何一門程式語言都可以用來開發API介面，而API介面的形式眾多，較常見的有：
1、基於HTTP協議的Web API
基於HTTP協議的API現在應用最廣，因為這類API是跨平臺跨語言的，看上去就和URL差不多。當下流行的RESTful API其實也屬於Web API，透過HTTP動詞（GET、POST、DELETE、PUT等）來表達不同型別的請求。
2、RPC 介面
RPC指的是遠端過程呼叫，本質上是“客戶端/伺服器端”模式（C/S模式），透過RPC技術可以讓呼叫方像呼叫本地方法一樣快捷的呼叫遠端伺服器上的方法。
RPC類介面也支援多種協議（如：HTTP、TCP、UDP、或自定義協議），資料傳輸方式也是多種多樣的（最常用的是 Json、Binary、Protobuf ）。
3、Web Service 概念類介面
Web Service 其實並不是特指某一個技術，而是一類以Web形式提供的服務都可以稱之為Web Service，像上面說的Web API、RESTful、SOAP等都屬於Web Service範疇。
為什麼Web API最常用的請求型別是GET和POST？的確，Web API請求時最常用的請求型別（HTTP動詞）是GET、POST。在RESTful風格推出之前，我們的介面傳參是少數的一般用GET請求，引數較多的就用POST請求。
但隨著RESTful風格推出後，我們是用不同的HTTP動詞來代表不同的請求，如：
GET：獲取資源
POST：建立資源
PUT：更新資源
但為什麼感覺GET和POST居多呢？原因有以下幾點：
現在還有很多Web API沒有按照RESTful風格建議來編寫API；
即使是RESTful風格型別的API，PUT、DELETE這類動詞其實也是建議在POST動詞基礎之上的。
-
4 # 山羊AM
大家規範就好了嗎，用什麼不重要，不是非必要的更新，這些小節無需拘束。除非下一代儲存方式都改變了，就不用http協議了
-
5 # 聖殿雷影
Put和Delete也常用，而且要注意的是Post不是冪等操作。當客戶端有重試需求時，API設計要儘量避免Post，改用Put。
-
6 # wooline
歸類是為了提取事物的共性，更好的複用和封裝。比如利用冪等的特性，你可以寫個全域性攔截方法，一旦get介面呼叫失敗，你可以自動重試。對於deleted的介面，你可以統一彈出確認警告。不僅如此，如果你的介面是一個公共的services，那麼很多第三方的proxy都可以對不同的method做一些不同的處理策略
-
7 # 上若止水10635501
我們的系統只允許用get post，一旦支援delete put head等，立馬開除，因為第三方安全公司認為這是重大風險！
-
8 # java架構設計
就為這事，上家公司一前端和後端幹起來了，後端寫了一介面，用put請求方式，前端開發在火狐瀏覽器上提示跨域，跨域是nginx統一處理的，換google瀏覽器、360瀏覽器都正常訪問。然後就讓後端看看，後端這哥們不管三七二十一，說在postman請求是ok的，前端這個時候不幹了，你這介面訪問跨域意味著介面不通呀，要求換成POST，後端同學不幹，說我這個是遵循resultful規範的，修改資料就得用PUT，不應該是POST，而且我用postman請求是ok的。
問題來了，這種事情到底是前端處理還是後端處理？
從技術角度來說，我們應該是解決問題，而不應該規避問題對吧？
解決問題的前提是得發現產生問題得本質原因是什麼，如果問題能解決，大家就一起解決，如果這個問題屬於三方問題，那就只能去規避這個問題。
後來經過大家檢查發現是火狐瀏覽器的一個小bug，不容易復現，那這個問題沒法解決了，這個時候就協商讓後端改成POST試試，那後端就願意改了。
後端這哥們的態度就是：“你要說你不行，那咱就給你解決，但是你不能說是我的問題”。
故事說完了～
restful應不應該用？我個人是傾向於在介面程式設計中只用get和post的，任你resultful規範的介面說的天花亂墜，可是我寫的介面就兩種：資料查詢就GET，資料變更就POST。但是我也從不限制別人使用PUT、DELETE請求。
但是需要有一些注意的地方，比如有的介面統計是基於nginx日誌的，那麼resultful風格的介面可能給統計帶來一些問題或者額外的工作量。
例如一個商品詳情介面：GET xxx/goods/1
你說你要統計這個介面的訪問數量，就得走匹配模式，如果是多引數的，或者沒有規則字首的那就無法統計了。
還有的老專案，介面互動用的是表單形式，而不是application/json，那就是清一色的post介面，你也別想著什麼規範不規範了。
最重要的一點：介面是寫給客戶端用的，要和客戶端多商量，定義好介面文件。
-
9 # shawn25
因為十幾年前http1.0的時候根本沒有 put delete 這些方法， 在後來的1.1版本中才增加了put ， delete等方法。
於是有些人就死活不用http1.1的新方法， 覺得新方法是魔鬼。
現在是全面向http2.0迭代的時代，http2.0也增加了很多新特性。
所以我預計十年之後，會有人提問題：“為什麼web開發中不用伺服器推送？”
這就和大家對Windows的態度一樣。
我還記得當年windows xp 剛出來的時候，一堆人狂噴xp是垃圾，完全不如win 98好用。
然後windows 7出來了，又有一堆人開始狂噴windows 7 是垃圾系統， xp多好用，多經典。
然後到了現在，win10出來了，又開始狂噴win10拆機垃圾，win7才是windows最經典的系統。
嗯，可能基本上都是一波人。
-
10 # RayTang1991
首先，從來都沒有人說只用get和post。你得先明白協議是什麼，協議就是用來約束行為，減輕溝通成本。但是這跟能不能達到目的沒有關係。本質上只要你能發出請求，後端能接到請求，那麼功能就能實現。具體用什麼方法，要不要遵循協議那都是你自己的事。
-
11 # 宇悅有言
獲取資訊用get，
建立資訊用post，
更改資訊用put，
我們是這樣用的，感覺很明確介面的使用方式，就是介面的定義好像會很多。
各有優劣吧。
-
12 # SingWing
除了這兩個，如果還有理由用其他的，比如PUT、DELETE等，那很可能就是restful了。但我個人一直都不太認可restful，理由基本只有一個，那就是：許多時候，從使用者的角度，一次對伺服器端的api請求，往往並不是一次單一的插入、修改或刪除，而是需要多種對不同資料實體的操作進行組合。restful我們認為增加了一些前端的工作量，且對許可權管理帶來了影響，尤其是傳統的企業級和政府應用系統。
當然，從設計和工程上，這涉及到對業務切分、分工、效能、安全、許可權等各方面的考慮。我們構建的業務系統，更傾向於從使用者的角度按業務切分api，並允許適當的介面冗餘（我們在實踐中發現，這有時候“違背”了過去人們所倡導的程式碼重用原則），然後將強內聚的一組api組織為一個授權單元。使用者在進行許可權管理時，是按自己熟悉的業務的方式進行管理，而不是按頁面、api甚至按鈕管理許可權。
我們的團隊約定，除了靜態資源使用get，其他一律使用post。
我們認為restful更多是從程式設計師的角度考慮問題的。但是，這個世界已經發展到應該從使用者的角度來考慮和設計。
那麼排除了restful或類似的框架之後，post、put等並沒有本質上的區別。
-
13 # zxeoc
居然還有人說按規範做浪費時間？各方都按規範做可以大幅減少溝通時間，而且以後再對接其他第三方也一樣可以節省時間。菜就說菜，不要給自己的菜找那麼多借口
回覆列表
開啟除錯工具我們可以看到除了get和post，還有put、delete方法，那為啥只用到get和post呢？
GET：從伺服器檢索內容或者實體在HTTP術語。GET請求通常不包含請求體，但是是被允許的。一些網路快取裝置僅僅GET方式響應。GET請求通常不會導致伺服器資料變化。
POST：用客戶端提供的資料更新實體。一個POST請求通常在請求體中包含資訊，這些資訊在應用伺服器是可以被使用的。POST請求被認為是非冪等性的，意味著如果多個請求被處理和僅僅一個請求被處理結果是不一樣的。
PUT：新增一個由客戶端提供的資料實體。一個PUT請求通常在請求體包含伺服器用來建立新實體用的資訊。通常，PUT請求被認為是冪等性的，意味著請求可以反覆使用相同應用的結果。
其實還有其他一些方法，多是輔助使用的，這裡就不談論了。
可以看到這四個方法分別對應增、刪、改、查功能，下面來逐個分析。
GET請求，提供查詢功能，可將查詢條件拼接在url後面。url是有字元長度限制的，長度根據瀏覽器和伺服器決定，其次由於url是完全暴露的，從安全形度看，涉及重要資訊或資源的介面，不推薦使用。
POST請求，是非冪等性的，可區域性更新資源也可全量更新資源，非常靈活，而且資料傳輸使用json格式，非常直觀易懂，這也是很多介面採用POST請求的原因。
PUT請求，是冪等性，請求多次結果都是相同的，在實用時有很大的侷限性，一般用於非常重要的防重的操作介面，比如發起支付，由於客戶端的抖動或其他原因導致重複請求介面，這時可以用PUT請求，但這也導致很多邏輯處理必須在伺服器實現，大大降低了伺服器的效率，其實防止重複請求介面可以用其他的簡便方法處理，這裡就不展開談論了。
透過以上分析可以看出，使用最多的POST請求，確實是因為它使用方便，當然也更開發者的習慣有關。以上四個方法，我司都有使用，主要是POST請求為主，其他三個方法根據特定需求使用的。