
一、前言
- 網(wǎng)絡(luò)編程是一種實(shí)時(shí)更新應(yīng)用數(shù)據(jù)的常用手段
- 網(wǎng)絡(luò)編程是開(kāi)發(fā)優(yōu)秀網(wǎng)絡(luò)應(yīng)用的前提和基礎(chǔ)
- 移動(dòng)網(wǎng)絡(luò)應(yīng)用 = 良好的UI + 良好的用戶體驗(yàn) + 實(shí)時(shí)更新的數(shù)據(jù)
| 類(lèi)別: | 案例1 | 案例2 | 案例3 | 案例4 |
|---|---|---|---|---|
| 新聞: | 網(wǎng)易新聞 | 新浪新聞 | 搜狐新聞 | 騰訊新聞 |
| 視頻: | 優(yōu)酷 | 百度視頻 | 搜狐視頻 | 愛(ài)奇藝視頻 |
| 音樂(lè): | QQ音樂(lè) | 百度音樂(lè) | 酷狗音樂(lè) | 酷我音樂(lè) |
| LBS: | 百度地圖 | 高德地圖 | 大眾點(diǎn)評(píng) | 墨跡天氣 |
| 電商: | 淘寶 | 京東商城 | 天貓 | 蘑菇街 |
| 社交: | 微信 | 微博 | 陌陌 |
- URL的全稱(chēng)是
Uniform Resource Locator(統(tǒng)一資源定位符) - 通過(guò)1個(gè)URL,能找到互聯(lián)網(wǎng)上唯一的1個(gè)資源URL就是資源的地址、位置
- 互聯(lián)網(wǎng)上的每個(gè)資源都有一個(gè)唯一的URL
- (1)HTTP
超文本傳輸協(xié)議,訪問(wèn)的是遠(yuǎn)程的網(wǎng)絡(luò)資源,格式是http://
http協(xié)議是在網(wǎng)絡(luò)開(kāi)發(fā)中最常用的協(xié)議 - (2)file
訪問(wèn)的是本地計(jì)算機(jī)上的資源,格式是file://(不用加主機(jī)地址) - (3)mailto
訪問(wèn)的是電子郵件地址,格式是mailto: - (4)FTP
訪問(wèn)的是共享主機(jī)的文件資源,格式是ftp://
二、HTTP
- HTTP的全稱(chēng)是Hypertext Transfer Protocol,超文本傳輸協(xié)議
- HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議,由于其簡(jiǎn)捷、快速的方式,適用于分布式超媒體信息系統(tǒng)。它于1990年提出,經(jīng)過(guò)幾年的使用與發(fā)展,得到不斷地完善和擴(kuò)展。
- 1.支持客戶/服務(wù)器模式。
- 2.簡(jiǎn)單快速:客戶向服務(wù)器請(qǐng)求服務(wù)時(shí),只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET,POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類(lèi)型不同。由于HTTP協(xié)議簡(jiǎn)單,使得HTTP服務(wù)器的程序規(guī)模小,因而通信速度很快。
- 3.靈活:HTTP允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念?lèi)型由Content-Type加以標(biāo)記。
- 4.無(wú)連接:無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求,并收到客戶的應(yīng)答后,即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。
- 5.無(wú)狀態(tài):HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息,則它必須重傳,這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面,在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。
- 6.面向鏈接的協(xié)議。
- 1、客戶機(jī)(瀏覽器)主動(dòng)向服務(wù)器(web server)發(fā)出連接請(qǐng)求。
- 2、服務(wù)器接受連接請(qǐng)求并建立起連接。
- 3、客戶機(jī)通過(guò)此連接向服務(wù)器發(fā)出GET等http命令。
- 4、服務(wù)器接到命令并根據(jù)命令向客戶機(jī)傳送相應(yīng)的數(shù)據(jù)。
- 5、客戶機(jī)接收從服務(wù)器送過(guò)來(lái)的數(shù)據(jù)。
- 6、服務(wù)器發(fā)送完數(shù)據(jù)后,主動(dòng)關(guān)閉此次連接。
-
完整的http通信可以分為2大步驟
(1)請(qǐng)求:客戶端向服務(wù)器索要數(shù)據(jù)
(2)響應(yīng):服務(wù)器返回客戶端相應(yīng)的數(shù)據(jù)
-
請(qǐng)求
HTTP協(xié)議規(guī)定:1個(gè)完整的由客戶端發(fā)給服務(wù)器的HTTP請(qǐng)求中包含以下內(nèi)容
請(qǐng)求行:包含了請(qǐng)求方法、請(qǐng)求資源路徑、HTTP協(xié)議版本
GET /MJServer/resources/images/1.jpg HTTP/1.1
請(qǐng)求頭:包含了對(duì)客戶端的環(huán)境描述、客戶端請(qǐng)求的主機(jī)地址等信息
Host: 192.168.1.105:8080// 客戶端想訪問(wèn)的服務(wù)器主機(jī)地址
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9) Firefox/30.0
//客戶端的類(lèi)型,客戶端的軟件環(huán)境
Accept: text/html // 客戶端所能接收的數(shù)據(jù)類(lèi)型
Accept-Language: zh-cn // 客戶端的語(yǔ)言環(huán)境
Accept-Encoding: gzip // 客戶端支持的數(shù)據(jù)壓縮格式
請(qǐng)求體:客戶端發(fā)給服務(wù)器的具體數(shù)據(jù),比如文件數(shù)據(jù)
-
響應(yīng)
客戶端向服務(wù)器發(fā)送請(qǐng)求,服務(wù)器應(yīng)當(dāng)做出響應(yīng),即返回?cái)?shù)據(jù)給客戶端
HTTP協(xié)議規(guī)定:1個(gè)完整的HTTP響應(yīng)中包含以下內(nèi)容:
狀態(tài)行:包含了HTTP協(xié)議版本、狀態(tài)碼、狀態(tài)英文名稱(chēng)
HTTP/1.1 200 OK
響應(yīng)頭:包含了對(duì)服務(wù)器的描述、對(duì)返回?cái)?shù)據(jù)的描述
Server: Apache-Coyote/1.1 // 服務(wù)器的類(lèi)型
Content-Type: image/jpeg // 返回?cái)?shù)據(jù)的類(lèi)型
Content-Length: 56811 // 返回?cái)?shù)據(jù)的長(zhǎng)度
Date: Mon, 23 Jun 2014 12:54:52 GMT // 響應(yīng)的時(shí)間
實(shí)體內(nèi)容:服務(wù)器返回給客戶端的具體數(shù)據(jù),比如文件數(shù)據(jù)

狀態(tài)代碼有三位數(shù)字組成,第一個(gè)數(shù)字定義了響應(yīng)的類(lèi)別,且有五種可能取值:
1xx:指示信息--表示請(qǐng)求已接收,繼續(xù)處理
2xx:成功--表示請(qǐng)求已被成功接收、理解、接受
3xx:重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
4xx:客戶端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)
5xx:服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求
常見(jiàn)狀態(tài)代碼、狀態(tài)描述、說(shuō)明:
200 OK //客戶端請(qǐng)求成功
400 Bad Request //客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤,不能被服務(wù)器所理解
401 Unauthorized //請(qǐng)求未經(jīng)授權(quán),這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用
403 Forbidden //服務(wù)器收到請(qǐng)求,但是拒絕提供服務(wù)
404 Not Found //請(qǐng)求資源不存在,eg:輸入了錯(cuò)誤的URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求,一段時(shí)間后可能恢復(fù)正常
-
在HTTP/1.1協(xié)議中,定義了8種發(fā)送http請(qǐng)求的方法,如下:
GET 請(qǐng)求獲取Request-URI所標(biāo)識(shí)的資源
POST 在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)
HEAD 請(qǐng)求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭
PUT 請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源,并用Request-URI作為其標(biāo)識(shí)
DELETE 請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源
TRACE 請(qǐng)求服務(wù)器回送收到的請(qǐng)求信息,主要用于測(cè)試或診斷
CONNECT 保留將來(lái)使用
OPTIONS 請(qǐng)求查詢服務(wù)器的性能,或者查詢與資源相關(guān)的選項(xiàng)和需求
提示:最常用的是GET和POST(實(shí)際上GET和POST都能辦到增刪改查)
三、漫談GET與POST
GET和POST的主要區(qū)別表現(xiàn)在數(shù)據(jù)傳遞上
- GET
在請(qǐng)求URL后面以?的形式跟上發(fā)給服務(wù)器的參數(shù),多個(gè)參數(shù)之間用&隔開(kāi),比如http://ww.test.com/login?username=123&pwd=234&type=JSON
注意:由于瀏覽器和服務(wù)器對(duì)URL長(zhǎng)度有限制,因此在URL后面附帶的參數(shù)是有限制的,通常不能超過(guò)1KB
- POST
發(fā)給服務(wù)器的參數(shù)全部放在請(qǐng)求體中
理論上,POST傳遞的數(shù)據(jù)量沒(méi)有限制(具體還得看服務(wù)器的處理能力)
選擇GET和POST的建議
(1)如果要傳遞大量數(shù)據(jù),比如文件上傳,只能用POST請(qǐng)求
(2)GET的安全性比POST要差些,如果包含機(jī)密\敏感信息,建議用POST
(3)如果僅僅是索取數(shù)據(jù)(數(shù)據(jù)查詢),建議使用GET
(4)如果是增加、修改、刪除數(shù)據(jù),建議使用POST
在iOS中,常見(jiàn)的發(fā)送HTTP請(qǐng)求(GET和POST)的解決方案有
- (1)蘋(píng)果原生(自帶)
- NSURLConnection:用法簡(jiǎn)單,ios9.0后廢棄
- NSURLSession:iOS 7新出的技術(shù),功能比NSURLConnection更加強(qiáng)大
- CFNetwork:NSURL*的底層,純C語(yǔ)言
- (2)第三方框架
- AFNetworking:簡(jiǎn)單易用,提供了基本夠用的常用功能
- Alamofile:swift版的AFNetworking
