這3個接口基礎知識,產(chǎn)品經(jīng)理需要知道
產(chǎn)品經(jīng)理在工作中,避免不了要閱讀接口文檔,希望本文能夠幫助大家更好的了解接口。
接口,即客戶端(瀏覽器)向服務器提交請求,服務器向客戶端返回響應。本質(zhì)就是數(shù)據(jù)的傳輸與接收。
本文主要介紹接口相關的基礎知識,包含接口的請求與響應、接口類型以及網(wǎng)絡協(xié)議。
一、請求與響應
1. 我們先來看一下請求 Request
它主要分為 3 個部分:General、Request Headers、Form Data. 我們來分別看一下每部分的詳細信息。
對于 General 部分,我們著重掌握下面這3個信息即可。
Request URL 代表的是請求的 Url 地址;
Request Method 代表的是請求方法,常用的請求方法有 Get、Post、Put、Delete。其中,應用最多的是 Get 和 Post 這 2 類。一般 Get 請求用來獲取數(shù)據(jù),Post 請求用來發(fā)送數(shù)據(jù);
Status Code 代表的是狀態(tài)碼,常見的狀態(tài)碼有下面幾類,本例中的 200 OK 表示請求正常處理完畢。
Request Headers 即請求頭,我們對主要字段進行逐一的介紹;
- Accept: 告訴服務器我們能接受的文件類型,服務器端使用 Content-Type 應答頭通知客戶端它的選擇?;
- Accept-Language: 客戶端所使用的語言;
- Accept-Encoding: 客戶端能接受的編碼格式? gzip : 壓縮字節(jié),為了節(jié)約帶寬,將服務器發(fā)送的內(nèi)容先通過 gzip 壓縮后發(fā)給客戶端,客戶端再解壓展示。HTTP 2.0 可以壓縮 header部分? HTTP1.1 只能壓縮 body 部分;
- Connection:有2種,分別是長連接和短連接:
- Keep-Alive-長連接:長連接就類似于打電話,我們之間可以一直保持連接狀態(tài),直至掛斷電? 話。缺點是一直占用連接池,直至連接超時。
- 短連接:短連接類似于發(fā)短信,我給你發(fā)送一條消息后,我們之間的連接即終止,每次發(fā)短信,? 都要新建一次連接。接口都是短連接,網(wǎng)站都是長連接。因為接口往往是針對某一個調(diào)用返回,接口一直為某個用戶服務時,才會長連接。
- User-Agent: 告訴服務器我的客戶端的類型,服務器通過user-agent來識別客戶端。
最后,我們來看一下 Form Data 請求體,
這部分,就是客戶端要發(fā)送給服務器端的數(shù)據(jù),可以看到,這個請求的 Form Data 中包含了用戶名、密碼等信息。我們會在發(fā)送請求時,把這些信息一并發(fā)送給服務器。
該例中,是一個 Post 請求,如果是 Get 請求,要傳輸?shù)膮?shù)會在 url 中顯示,通過 ‘ ? ’ 與請求地址隔開。形式如下:
2. 響應 Response
Response 主要分為 2 個部分,Header 部分和 Body 部分,這 2 部分展示如下圖所示;
Header 部分的內(nèi)容,多數(shù)是與請求頭相對應的,Body 部分就是瀏覽器看到的內(nèi)容。
在有的 Response 響應頭中,會有這樣一個字段 Last-modified,在這里為大家介紹一下。
Last-modified 顯示的是服務器上文件的最后修改時間,當我們請求時,會判斷該文件的最后修改時間和本地上的文件時間是否是一致的,如果一致,那么 body 部分會直接用緩存,不再下載,只下載 header 就可以了,這樣可以提高效率,節(jié)省網(wǎng)絡資源。
二、接口類型
比較常見的接口類型有 WebService 和 HTTPService ,它們有如下主要區(qū)別:
- 基于不同的協(xié)議:HTTPService 基于 Http 協(xié)議,而 WebService 基于 soap 協(xié)議;
- 跨域的處理:HttpService 方式不能處理跨域,如果調(diào)用一個其它應用的服務就要用WebService;
- 處理數(shù)據(jù)效率不同:HTTPService 效率較高,而 WebService 能處理較復雜的數(shù)據(jù)類型。
當調(diào)用一個本服務的內(nèi)容時,不涉及到跨域的問題,可以使用 HttpService 的方式。
如果,需要在后臺調(diào)用一個其它應用的服務,這個時候,就必須要用 WebService 的方式來調(diào)用。
簡單的說, WebService 是不依賴于語言,不依賴于平臺,可以實現(xiàn)不同的語言、異構系統(tǒng)間的相互調(diào)用。
三、網(wǎng)絡協(xié)議
我們常常聽說 TCP/IP 協(xié)議,其實,TCP/IP 協(xié)議是一個協(xié)議簇,里面是包括很多協(xié)議的,之所以命名為 TCP/IP 協(xié)議,是因為 TCP、IP 協(xié)議是兩個很重要的協(xié)議,所以就用他們命名了。
一個 TCP 連接必須要經(jīng)過三次“對話”才能建立起來。
大家應該都聽說過3次握手,但不知道具體是怎么回事,在這里為大家形象的解釋下3次握手的過程:
主機 A 先向主機 B 發(fā)出連接請求的數(shù)據(jù)包:“我想給你發(fā)數(shù)據(jù),是否可以”,這是第一次對話;
接下來,主機B向主機A發(fā)送數(shù)據(jù)包:“可以,什么時候發(fā)?”,這是第二次對話;
接下來,主機A再發(fā)出一個數(shù)據(jù)包:“現(xiàn)在就發(fā)”,這是第三次對話。
經(jīng)過三次“對話”之后,主機A才向主機B正式發(fā)送數(shù)據(jù)。
這就是我們常常聽說的3次握手的過程。
那么,不光有3次握手,當斷開連接時,我們還需要4次揮手:
A: 數(shù)據(jù)傳完了,可以停止嗎?
B: 消息收到,請稍等!
B: 好了,可以停止了。
A: 好的,過一會兒沒有消息我就關閉啦。
最后,通過上面的介紹,我們了解了接口的請求與響應信息,接口的主要類型以及它們的主要區(qū)別,另外,還為大家科普了 3 次握手和 4 次揮手的過程,希望幫助大家掌握對接口更深層次的理解。
本文由 @清晨 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
講點業(yè)務方面的知識吧。
感謝大大 小白受益匪淺
通俗易懂