產(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ū)別：

1. 基于不同的協(xié)議：HTTPService 基于 Http 協(xié)議，而 WebService 基于 soap 協(xié)議；
2. 跨域的處理：HttpService 方式不能處理跨域，如果調(diào)用一個其它應用的服務就要用WebService；
3. 處理數(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é)議