大家一般用什么工具測試HTTP和json接口？SoupUI，這是我現(xiàn)在用的最多的接口測試工具。在我們?nèi)粘５拈_發(fā)過程中，大多數(shù)是兩種類型的接口：SOAP API和Rest API兩種，SoupUI對這兩

大家一般用什么工具測試HTTP和json接口？

SoupUI，這是我現(xiàn)在用的最多的接口測試工具。

在我們?nèi)粘５拈_發(fā)過程中，大多數(shù)是兩種類型的接口：SOAP API和Rest API兩種，SoupUI對這兩種接口都有很好的支持，而且還支持Amazon Web Service，這個只在軟件的首頁上看到過，沒有實際使用過。

其實很多的接口測試工具對這兩種常用的接口都有很好的支持，具體的使用方法我在這里也不詳細(xì)講了，都是圖形界面的操作，按照指示一步一步的新建即可完成。

其中它可以很方便地進(jìn)行壓力測試，也是按照提示，一步一步新建，最后的的操作頁面是這樣的：

可以設(shè)置：并發(fā)數(shù)、策略，壓力測試的時間等。

結(jié)果可以展示：接口的最大響應(yīng)時間、最小響應(yīng)時間、平均響應(yīng)時間、TPS等等。

非常好用，大家可以嘗試。

希望我的回答，能夠幫助到你！我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計、職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注；另外，關(guān)注我后私信【資料】兩個字，可獲取架構(gòu)、大數(shù)據(jù)、面試等相關(guān)資料。

后端開發(fā)完接口才給出接口文檔，合理嗎？你怎么看？

一個非常好的問題，我是工作多年的Web應(yīng)用架構(gòu)師，來回答一下這個問題。歡迎關(guān)注我，了解更多IT專業(yè)知識。

后端給出接口文檔太晚，也合理也不合理，要看具體情況，總有解決方法，我來說一下我的觀點。

不合理：成熟的技術(shù)團隊，重視功能設(shè)計，在動手寫代碼之前已經(jīng)有了完整的技術(shù)文檔和功能定義，甚至在TDD測試驅(qū)動開發(fā)模式中，測試數(shù)據(jù)已經(jīng)準(zhǔn)備就緒，那么這時接口文檔不管寫沒寫，接口邏輯都是已經(jīng)確定的，整理出來是水到渠成。

合理：多存在于早期小型創(chuàng)業(yè)公司，主觀客觀原因都有。

- 先說主觀原因。趕進(jìn)度、沒時間、懶得寫，甚至開發(fā)前都沒做仔細(xì)的設(shè)計，邊做邊改，這些原因普遍存在，也實在沒啥好辦法。

- 客觀原因，需求在變，功能跟著變，接口也要變，那么如果寫了文檔，理所當(dāng)然也要更新維護啊？我的天哪。

有解決方法嗎？建議試試：

1，Swagger接口文檔，將文檔融合到代碼中，讓維護文檔和修改代碼整合為一體，使得修改代碼邏輯的同時方便的修改文檔說明。

2，Postman接口測試工具，導(dǎo)入導(dǎo)出JSON文件，高效團隊協(xié)作。Postman支持各種請求方式和配置環(huán)境變量，并對返回結(jié)果進(jìn)行測試校驗，支持批量自動化運行，可以和自動構(gòu)建系統(tǒng)集成。

application/json和application/x-www-form-urlencode的區(qū)別？

application/json：是JSON格式提交的一種識別方式。在請求頭里標(biāo)示。

application/x-www-form-urlencoded：這是form表單提交的時候的表示方式。

比如我們ajax提交，如果dataType是json，那么請求頭就是application/json，而我們平常的form提交那么就是application/x-www-form-urlencoded，自己瀏覽器控制臺看看就知道了。

有什么JSON問題請咨詢我。知無不答。

JSON在線解析：http://www.sojson.com/

接口編程中，為什么只用get和post？

Get，post就足夠用了。。搞什么restful規(guī)范的接口，活干完就不錯了，別整那些花里胡哨的