當(dāng)前，作為大部分移動app和云服務(wù)后臺之間的標(biāo)準(zhǔn)連接方式，REST API已經(jīng)得到了絕大部分開發(fā)者的認(rèn)可和廣泛的應(yīng)用。近年來，在新興API經(jīng)濟(jì)模式逐漸興起，許多廠商紛紛將自己的后臺業(yè)務(wù)能力作為REST API開放出來，給更廣泛的第三方開發(fā)者使用。

 

但是，管理REST API并非是一件容易的工作。由于缺乏有效的接口數(shù)據(jù)schema約束，加上設(shè)計REST API時resource endpoint的安排，以及發(fā)送http請求的方式又都五花八門，REST API開發(fā)完成后，大多數(shù)情況下API開發(fā)者仍然需要手動書寫API文檔，讓用戶能按照文檔的說明接入。并且在API發(fā)生變化時需要重寫文檔，這個過程費(fèi)時費(fèi)力而且容易出錯。比如，一個REST API文檔最少必須列明以下的基本信息：

 

* API的名稱

* API所在的URL資源路徑

* http請求方法（GET, POST, PUT等）

* API提交數(shù)據(jù)的方式（查詢參數(shù)、表單提交、JSON提交等）

* 調(diào)用API返回數(shù)據(jù)的格式

 

在上面提供的REST API信息中，從API返回的JSON數(shù)據(jù)在大部分情況下甚至只能用“舉例”的方法說明數(shù)據(jù)的結(jié)構(gòu)，而無法精確表達(dá)出這段JSON數(shù)據(jù)中每個字段的精確含義和類型定義。這都是因?yàn)镽EST API缺少對JSON數(shù)據(jù)的schema定義而