深入理解什么是RESTful API ？

前言：最近兩年很火爆的網(wǎng)絡(luò)框架Retrofit务嫡，使用它的時(shí)候甲抖，查看文檔會(huì)告訴你漆改，要求后臺(tái)的服務(wù)器哥們必須符合REST規(guī)范給你設(shè)計(jì)接口，作為安卓開發(fā)工程師來說准谚，我就很奇怪了挫剑，REST規(guī)范到底是啥？本著極客精神氛魁，我就查了資料暮顺，寫了這么一篇文章，如果有不對(duì)的地方秀存，歡迎提意見捶码。

本文轉(zhuǎn)載自：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

一、理解RESTful架構(gòu)

越來越多的人開始意識(shí)到或链，網(wǎng)站即軟件惫恼，而且是一種新型的軟件。
　　這種"互聯(lián)網(wǎng)軟件"采用客戶端/服務(wù)器模式澳盐，建立在分布式體系上祈纯，通過互聯(lián)網(wǎng)通信，具有高延時(shí)（high latency）叼耙、高并發(fā)等特點(diǎn)腕窥。
　　網(wǎng)站開發(fā)，完全可以采用軟件開發(fā)的模式筛婉。但是傳統(tǒng)上，軟件和網(wǎng)絡(luò)是兩個(gè)不同的領(lǐng)域爽撒，很少有交集；軟件開發(fā)主要針對(duì)單機(jī)環(huán)境硕勿，網(wǎng)絡(luò)則主要研究系統(tǒng)之間的通信哨毁《笸剩互聯(lián)網(wǎng)的興起，使得這兩個(gè)領(lǐng)域開始融合抄沮，** 現(xiàn)在我們必須考慮，如何開發(fā)在互聯(lián)網(wǎng)環(huán)境中使用的軟件刻伊。**

RESTful架構(gòu)，就是目前最流行的一種互聯(lián)網(wǎng)軟件架構(gòu)。它結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)愧怜、易于理解渴逻、擴(kuò)展方便惨奕，所以正得到越來越多網(wǎng)站的采用卧波。
　　但是港粱，到底什么是RESTful架構(gòu)寸宏，并不是一個(gè)容易說清楚的問題罩阵。下面鞋仍，我就談?wù)勎依斫獾腞ESTful架構(gòu)溃斋。

一、起源

REST這個(gè)詞走哺，是Roy Thomas Fielding在他2000年的博士論文中提出的废恋。


　　Fielding是一個(gè)非常重要的人，他是HTTP協(xié)議（1.0版和1.1版）的主要設(shè)計(jì)者隔披、Apache服務(wù)器軟件的作者之一、Apache基金會(huì)的第一任主席。所以，他的這篇論文一經(jīng)發(fā)表揩魂，就引起了關(guān)注没炒，并且立即對(duì)互聯(lián)網(wǎng)開發(fā)產(chǎn)生了深遠(yuǎn)的影響犯戏。
　　他這樣介紹論文的寫作目的：

本文研究計(jì)算機(jī)科學(xué)兩大前沿----軟件和網(wǎng)絡(luò)----的交叉點(diǎn)送火。長(zhǎng)期以來，軟件研究主要關(guān)注軟件設(shè)計(jì)的分類先匪、設(shè)計(jì)方法的演化种吸，很少客觀地評(píng)估不同的設(shè)計(jì)選擇對(duì)系統(tǒng)行為的影響。而相反地呀非，網(wǎng)絡(luò)研究主要關(guān)注系統(tǒng)之間通信行為的細(xì)節(jié)坚俗、如何改進(jìn)特定通信機(jī)制的表現(xiàn)，常常忽視了一個(gè)事實(shí)岸裙，那就是改變應(yīng)用程序的互動(dòng)風(fēng)格比改變互動(dòng)協(xié)議猖败，對(duì)整體表現(xiàn)有更大的影響。我這篇文章的寫作目的哥桥，就是想在符合架構(gòu)原理的前提下辙浑，理解和評(píng)估以網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用軟件的架構(gòu)設(shè)計(jì)，得到一個(gè)功能強(qiáng)拟糕、性能好判呕、適宜通信的架構(gòu)。

二送滞、名稱

Fielding將他對(duì)互聯(lián)網(wǎng)軟件的架構(gòu)原則侠草，定名為REST，即Representational State Transfer的縮寫犁嗅。我對(duì)這個(gè)詞組的翻譯是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"边涕。

如果一個(gè)架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)褂微。

要理解RESTful架構(gòu)功蜓，最好的方法就是去理解Representational State Transfer這個(gè)詞組到底是什么意思，它的每一個(gè)詞代表了什么涵義宠蚂。如果你把這個(gè)名稱搞懂了式撼，也就不難體會(huì)REST是一種什么樣的設(shè)計(jì)。

三求厕、資源（Resources）

REST的名稱"表現(xiàn)層狀態(tài)轉(zhuǎn)化"中著隆，省略了主語扰楼。"表現(xiàn)層"其實(shí)指的是"資源"（Resources）的"表現(xiàn)層"。

所謂"資源"美浦，就是網(wǎng)絡(luò)上的一個(gè)實(shí)體弦赖，或者說是網(wǎng)絡(luò)上的一個(gè)具體信息。它可以是一段文本浦辨、一張圖片蹬竖、一首歌曲、一種服務(wù)流酬，總之就是一個(gè)具體的實(shí)在案腺。你可以用一個(gè)URI（統(tǒng)一資源標(biāo)識(shí)符）指向它，每種資源對(duì)應(yīng)一個(gè)特定的URI康吵。要獲取這個(gè)資源，訪問它的URI就可以访递，因此URI就成了每一個(gè)資源的地址或獨(dú)一無二的識(shí)別符晦嵌。

附：
URI：Uniform Resource Identifier，統(tǒng)一資源標(biāo)識(shí)符
URL：Uniform Resource Location統(tǒng)一資源定位符

所謂"上網(wǎng)"拷姿，就是與互聯(lián)網(wǎng)上一系列的"資源"互動(dòng)惭载，調(diào)用它的URI。

四响巢、表現(xiàn)層（Representation）

"資源"是一種信息實(shí)體描滔，它可以有多種外在表現(xiàn)形式。我們把"資源"具體呈現(xiàn)出來的形式踪古，叫做它的"表現(xiàn)層"（Representation）含长。

比如，文本可以用txt格式表現(xiàn)伏穆，也可以用HTML格式拘泞、XML格式、JSON格式表現(xiàn)枕扫，甚至可以采用二進(jìn)制格式陪腌；圖片可以用JPG格式表現(xiàn)，也可以用PNG格式表現(xiàn)烟瞧。

URI只代表資源的實(shí)體诗鸭，不代表它的形式。嚴(yán)格地說参滴，有些網(wǎng)址最后的".html"后綴名是不必要的强岸，因?yàn)檫@個(gè)后綴名表示格式，屬于"表現(xiàn)層"范疇卵洗，而URI應(yīng)該只代表"資源"的位置请唱。它的具體表現(xiàn)形式弥咪，應(yīng)該在HTTP請(qǐng)求的頭信息中用Accept和Content-Type字段指定，這兩個(gè)字段才是對(duì)"表現(xiàn)層"的描述十绑。

五聚至、狀態(tài)轉(zhuǎn)化（State Transfer）

訪問一個(gè)網(wǎng)站，就代表了客戶端和服務(wù)器的一個(gè)互動(dòng)過程本橙。在這個(gè)過程中扳躬，勢(shì)必涉及到數(shù)據(jù)和狀態(tài)的變化。

互聯(lián)網(wǎng)通信協(xié)議HTTP協(xié)議甚亭，是一個(gè)無狀態(tài)協(xié)議贷币。這意味著，所有的狀態(tài)都保存在服務(wù)器端亏狰。因此役纹，如果客戶端想要操作服務(wù)器，必須通過某種手段暇唾，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（State Transfer）促脉。而這種轉(zhuǎn)化是建立在表現(xiàn)層之上的，所以就是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"策州。

客戶端用到的手段瘸味，只能是HTTP協(xié)議。具體來說够挂，就是HTTP協(xié)議里面旁仿，四個(gè)表示操作方式的動(dòng)詞：GET、POST孽糖、PUT枯冈、DELETE。它們分別對(duì)應(yīng)四種基本操作：GET用來獲取資源梭姓，POST用來新建資源（也可以用于更新資源）霜幼，PUT用來更新資源，DELETE用來刪除資源誉尖。

六罪既、綜述

綜合上面的解釋，我們總結(jié)一下什么是RESTful架構(gòu)：
　　　≌∷　（1）每一個(gè)URI代表一種資源琢感；
　　　　（2）客戶端和服務(wù)器之間探熔，傳遞這種資源的某種表現(xiàn)層驹针；
　　　　（3）客戶端通過四個(gè)HTTP動(dòng)詞诀艰，對(duì)服務(wù)器端資源進(jìn)行操作柬甥，實(shí)現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"饮六。

七、誤區(qū)

RESTful架構(gòu)有一些典型的設(shè)計(jì)誤區(qū)苛蒲。
　　最常見的一種設(shè)計(jì)錯(cuò)誤卤橄，就是URI包含動(dòng)詞。因?yàn)?資源"表示一種實(shí)體臂外，所以應(yīng)該是名詞窟扑，URI不應(yīng)該有動(dòng)詞，動(dòng)詞應(yīng)該放在HTTP協(xié)議中漏健。
　　舉例來說嚎货，某個(gè)URI是/posts/show/1，其中show是動(dòng)詞蔫浆，這個(gè)URI就設(shè)計(jì)錯(cuò)了殖属，正確的寫法應(yīng)該是/posts/1，然后用GET方法表示show瓦盛。
　　如果某些動(dòng)作是HTTP動(dòng)詞表示不了的忱辅，你就應(yīng)該把動(dòng)作做成一種資源。比如網(wǎng)上匯款谭溉，從賬戶1向賬戶2匯款500元，錯(cuò)誤的URI是：

POST /accounts/1/transfer/500/to/2

正確的寫法是把動(dòng)詞transfer改成名詞transaction橡卤，資源不能是動(dòng)詞扮念，但是可以是一種服務(wù)：

POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00

另一個(gè)設(shè)計(jì)誤區(qū)，就是在URI中加入版本號(hào)：

http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo

因?yàn)椴煌陌姹颈炭猓梢岳斫獬赏环N資源的不同表現(xiàn)形式柜与，所以應(yīng)該采用同一個(gè)URI。版本號(hào)可以在HTTP請(qǐng)求頭信息的Accept字段中進(jìn)行區(qū)分（參見Versioning REST Services）：

Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0

二嵌灰、RESTful API 設(shè)計(jì)指南

網(wǎng)絡(luò)應(yīng)用程序弄匕，分為前端和后端兩個(gè)部分。當(dāng)前的發(fā)展趨勢(shì)沽瞭，就是前端設(shè)備層出不窮（手機(jī)迁匠、平板、桌面電腦驹溃、其他專用設(shè)備......）城丧。
　　因此，必須有一種統(tǒng)一的機(jī)制豌鹤，方便不同的前端設(shè)備與后端進(jìn)行通信亡哄。這導(dǎo)致API構(gòu)架的流行，甚至出現(xiàn)"API First"的設(shè)計(jì)思想布疙。RESTful API是目前比較成熟的一套互聯(lián)網(wǎng)應(yīng)用程序的API設(shè)計(jì)理論蚊惯。我以前寫過一篇《理解RESTful架構(gòu)》愿卸，探討如何理解這個(gè)概念。
　　今天截型，我將介紹RESTful API的設(shè)計(jì)細(xì)節(jié)趴荸，探討如何設(shè)計(jì)一套合理、好用的API菠劝。我的主要參考了兩篇文章（1赊舶，2）。

RESTful API

一赶诊、協(xié)議

API與用戶的通信協(xié)議笼平，總是使用HTTPs協(xié)議。

二舔痪、域名

應(yīng)該盡量將API部署在專用域名之下寓调。

    https://api.example.com

如果確定API很簡(jiǎn)單，不會(huì)有進(jìn)一步擴(kuò)展锄码，可以考慮放在主域名下夺英。

     https://example.org/api/

三、版本（Versioning）

應(yīng)該將API的版本號(hào)放入U(xiǎn)RL滋捶。

　　https://api.example.com/v1/

另一種做法是痛悯，將版本號(hào)放在HTTP頭信息中，但不如放入U(xiǎn)RL方便和直觀重窟。Github采用這種做法载萌。

四、路徑（Endpoint）

路徑又稱"終點(diǎn)"（endpoint）巡扇，表示API的具體網(wǎng)址扭仁。

在RESTful架構(gòu)中，每個(gè)網(wǎng)址代表一種資源（resource）厅翔，所以網(wǎng)址中不能有動(dòng)詞乖坠，只能有名詞，而且所用的名詞往往與數(shù)據(jù)庫(kù)的表格名對(duì)應(yīng)刀闷。一般來說熊泵，數(shù)據(jù)庫(kù)中的表都是同種記錄的"集合"（collection），所以API中的名詞也應(yīng)該使用復(fù)數(shù)甸昏。

舉例來說戈次，有一個(gè)API提供動(dòng)物園（zoo）的信息，還包括各種動(dòng)物和雇員的信息筒扒，則它的路徑應(yīng)該設(shè)計(jì)成下面這樣怯邪。

https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees

五、HTTP動(dòng)詞

對(duì)于資源的具體操作類型花墩，由HTTP動(dòng)詞表示悬秉。
常用的HTTP動(dòng)詞有下面五個(gè)（括號(hào)里是對(duì)應(yīng)的SQL命令）澄步。

GET（SELECT）：從服務(wù)器取出資源（一項(xiàng)或多項(xiàng)）。
POST（CREATE）：在服務(wù)器新建一個(gè)資源和泌。
PUT（UPDATE）：在服務(wù)器更新資源（客戶端提供改變后的完整資源）村缸。
PATCH（UPDATE）：在服務(wù)器更新資源（客戶端提供改變的屬性）。
DELETE（DELETE）：從服務(wù)器刪除資源武氓。

還有兩個(gè)不常用的HTTP動(dòng)詞梯皿。

HEAD：獲取資源的元數(shù)據(jù)。
OPTIONS：獲取信息县恕，關(guān)于資源的哪些屬性是客戶端可以改變的东羹。

下面是一些例子。

GET /zoos：列出所有動(dòng)物園
POST /zoos：新建一個(gè)動(dòng)物園
GET /zoos/ID：獲取某個(gè)指定動(dòng)物園的信息
PUT /zoos/ID：更新某個(gè)指定動(dòng)物園的信息（提供該動(dòng)物園的全部信息）
PATCH /zoos/ID：更新某個(gè)指定動(dòng)物園的信息（提供該動(dòng)物園的部分信息）
DELETE /zoos/ID：刪除某個(gè)動(dòng)物園
GET /zoos/ID/animals：列出某個(gè)指定動(dòng)物園的所有動(dòng)物
DELETE /zoos/ID/animals/ID：刪除某個(gè)指定動(dòng)物園的指定動(dòng)物

六忠烛、過濾信息（Filtering）

如果記錄數(shù)量很多属提，服務(wù)器不可能都將它們返回給用戶。API應(yīng)該提供參數(shù)美尸，過濾返回結(jié)果冤议。
下面是一些常見的參數(shù)。

?limit=10：指定返回記錄的數(shù)量
?offset=10：指定返回記錄的開始位置师坎。
?page=2&per_page=100：指定第幾頁恕酸，以及每頁的記錄數(shù)。
?sortby=name&order=asc：指定返回結(jié)果按照哪個(gè)屬性排序胯陋，以及排序順序尸疆。
?animal_type_id=1：指定篩選條件

參數(shù)的設(shè)計(jì)允許存在冗余，即允許API路徑和URL參數(shù)偶爾有重復(fù)惶岭。比如，GET /zoo/ID/animals 與 GET /animals?zoo_id=ID 的含義是相同的犯眠。

七按灶、狀態(tài)碼（Status Codes）

服務(wù)器向用戶返回的狀態(tài)碼和提示信息，常見的有以下一些（方括號(hào)中是該狀態(tài)碼對(duì)應(yīng)的HTTP動(dòng)詞）筐咧。

200 OK - [GET]：服務(wù)器成功返回用戶請(qǐng)求的數(shù)據(jù)鸯旁，該操作是冪等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功量蕊。
202 Accepted - [*]：表示一個(gè)請(qǐng)求已經(jīng)進(jìn)入后臺(tái)排隊(duì)（異步任務(wù)）
204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功铺罢。
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請(qǐng)求有錯(cuò)誤，服務(wù)器沒有進(jìn)行新建或修改數(shù)據(jù)的操作残炮，該操作是冪等的韭赘。
401 Unauthorized - [*]：表示用戶沒有權(quán)限（令牌、用戶名势就、密碼錯(cuò)誤）晴裹。
403 Forbidden - [*] 表示用戶得到授權(quán)（與401錯(cuò)誤相對(duì)）洋腮，但是訪問是被禁止的房官。
404 NOT FOUND - [*]：用戶發(fā)出的請(qǐng)求針對(duì)的是不存在的記錄，服務(wù)器沒有進(jìn)行操作侧巨，該操作是冪等的。
406 Not Acceptable - [GET]：用戶請(qǐng)求的格式不可得（比如用戶請(qǐng)求JSON格式鞭达，但是只有XML格式）司忱。
410 Gone -[GET]：用戶請(qǐng)求的資源被永久刪除，且不會(huì)再得到的畴蹭。
422 Unprocesable entity - [POST/PUT/PATCH] 當(dāng)創(chuàng)建一個(gè)對(duì)象時(shí)坦仍，發(fā)生一個(gè)驗(yàn)證錯(cuò)誤。
500 INTERNAL SERVER ERROR - [*]：服務(wù)器發(fā)生錯(cuò)誤撮胧，用戶將無法判斷發(fā)出的請(qǐng)求是否成功桨踪。

狀態(tài)碼的完全列表參見這里。

八芹啥、錯(cuò)誤處理（Error handling）

如果狀態(tài)碼是4xx锻离，就應(yīng)該向用戶返回出錯(cuò)信息。一般來說墓怀，返回的信息中將error作為鍵名汽纠，出錯(cuò)信息作為鍵值即可。

{
error: "Invalid API key"
}

九傀履、返回結(jié)果

針對(duì)不同操作虱朵，服務(wù)器向用戶返回的結(jié)果應(yīng)該符合以下規(guī)范。

GET /collection：返回資源對(duì)象的列表（數(shù)組）
GET /collection/resource：返回單個(gè)資源對(duì)象
POST /collection：返回新生成的資源對(duì)象
PUT /collection/resource：返回完整的資源對(duì)象
PATCH /collection/resource：返回完整的資源對(duì)象
DELETE /collection/resource：返回一個(gè)空文檔

十钓账、Hypermedia API

RESTful API最好做到Hypermedia碴犬，即返回結(jié)果中提供鏈接，連向其他API方法梆暮，使得用戶不查文檔服协，也知道下一步應(yīng)該做什么。
　　比如啦粹，當(dāng)用戶向api.example.com的根目錄發(fā)出請(qǐng)求偿荷，會(huì)得到這樣一個(gè)文檔。

{"link": { 
  "rel":   "collection https://www.example.com/zoos",
  "href":  "https://api.example.com/zoos",
  "title": "List of zoos",
  "type":  "application/vnd.yourformat+json"
}}

上面代碼表示唠椭，文檔中有一個(gè)link屬性跳纳，用戶讀取這個(gè)屬性就知道下一步該調(diào)用什么API了。rel表示這個(gè)API與當(dāng)前網(wǎng)址的關(guān)系（collection關(guān)系贪嫂，并給出該collection的網(wǎng)址）寺庄，href表示API的路徑，title表示API的標(biāo)題，type表示返回類型铣揉。
　　Hypermedia API的設(shè)計(jì)被稱為HATEOAS饶深。Github的API就是這種設(shè)計(jì)，訪問api.github.com會(huì)得到一個(gè)所有可用API的網(wǎng)址列表逛拱。

{
  "current_user_url": "https://api.github.com/user",
  "authorizations_url": "https://api.github.com/authorizations",
  // ...
}

從上面可以看到敌厘，如果想獲取當(dāng)前用戶的信息，應(yīng)該去訪問api.github.com/user朽合，然后就得到了下面結(jié)果俱两。

  {
    "message": "Requires authentication",
    "documentation_url": "https://developer.github.com/v3"
}

上面代碼表示，服務(wù)器給出了提示信息曹步，以及文檔的網(wǎng)址宪彩。

十一、其他

（1）API的身份認(rèn)證應(yīng)該使用OAuth 2.0框架讲婚。
（2）服務(wù)器返回的數(shù)據(jù)格式尿孔，應(yīng)該盡量使用JSON，避免使用XML筹麸。
（完）

原文：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末活合，一起剝皮案震驚了整個(gè)濱河市，隨后出現(xiàn)的幾起案子物赶，更是在濱河造成了極大的恐慌白指，老刑警劉巖，帶你破解...
    沈念sama閱讀 216,324評(píng)論 6贊 498
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件酵紫，死亡現(xiàn)場(chǎng)離奇詭異告嘲，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)奖地，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,356評(píng)論 3贊 392
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門橄唬，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人参歹，你說我怎么就攤上這事仰楚。” “怎么了泽示？”我有些...
    開封第一講書人閱讀 162,328評(píng)論 0贊 353
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長(zhǎng)蜜氨。 經(jīng)常有香客問我械筛，道長(zhǎng)，這世上最難降的妖魔是什么飒炎？ 我笑而不...
    開封第一講書人閱讀 58,147評(píng)論 1贊 292
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任埋哟，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘赤赊。我一直安慰自己闯狱，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 67,160評(píng)論 6贊 388
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布抛计。 她就那樣靜靜地躺著哄孤，像睡著了一般。 火紅的嫁衣襯著肌膚如雪吹截。 梳的紋絲不亂的頭發(fā)上瘦陈，一...
    開封第一講書人閱讀 51,115評(píng)論 1贊 296
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音波俄，去河邊找鬼晨逝。 笑死，一個(gè)胖子當(dāng)著我的面吹牛懦铺，可吹牛的內(nèi)容都是我干的捉貌。 我是一名探鬼主播，決...
    沈念sama閱讀 40,025評(píng)論 3贊 417
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼冬念，長(zhǎng)吁一口氣：“原來是場(chǎng)噩夢(mèng)啊……” “哼趁窃！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起刘急，我...
    開封第一講書人閱讀 38,867評(píng)論 0贊 274
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對(duì)情侶失蹤棚菊，失蹤者是張志新（化名）和其女友劉穎，沒想到半個(gè)月后叔汁，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體统求，經(jīng)...
    沈念sama閱讀 45,307評(píng)論 1贊 310
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,528評(píng)論 2贊 332
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年据块，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了码邻。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 39,688評(píng)論 1贊 348
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡另假，死狀恐怖像屋，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情边篮，我是刑警寧澤己莺，帶...
    沈念sama閱讀 35,409評(píng)論 5贊 343
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站戈轿，受9級(jí)特大地震影響凌受，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜思杯，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,001評(píng)論 3贊 325
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一胜蛉、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦誊册、人聲如沸领突。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,657評(píng)論 0贊 22
  • 一樁弒父案案怯，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽君旦。三九已至，卻和暖如春殴泰，著一層夾襖步出監(jiān)牢的瞬間于宙，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,811評(píng)論 1贊 268
  • 情欲美人皮
    我被黑心中介騙來泰國(guó)打工悍汛， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留捞魁，地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 47,685評(píng)論 2贊 368
  • 代替公主和親
    正文 我出身青樓离咐，卻偏偏與公主長(zhǎng)得像谱俭，于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子宵蛀，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,573評(píng)論 2贊 353

推薦閱讀更多精彩內(nèi)容

  • 一說到REST昆著，我想大家的第一反應(yīng)就是“啊，就是那種前后臺(tái)通信方式术陶〈斩”但是在要求詳細(xì)講述它所提出的各個(gè)約束，以及如...
    時(shí)待吾閱讀 3,423評(píng)論 0贊 19
  • 從今天開始梧宫，我開始學(xué)習(xí)Retrofit接谨，整體Retrofit內(nèi)容如下： 1、Retrofit解析1之前哨站——理解...
    隔壁老李頭閱讀 6,112評(píng)論 4贊 46
  • 解釋一 REST -- REpresentational State Transfer 直接翻譯：表現(xiàn)層狀態(tài)轉(zhuǎn)移塘匣。...
    時(shí)間之友閱讀 2,234評(píng)論 0贊 10
  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具（例如配置管理脓豪，服務(wù)發(fā)現(xiàn)，斷路器忌卤，智...
    卡卡羅2017閱讀 134,651評(píng)論 18贊 139
  • 1.談機(jī)會(huì)的前提 古人說：君子藏器于身驰徊，待時(shí)而動(dòng)笤闯。這個(gè)“時(shí)”，就是機(jī)會(huì)棍厂。而藏器于身颗味，就是說我們要有所準(zhǔn)備，這是大前...
    虎七七閱讀 3,583評(píng)論 15贊 43