單文件實(shí)現(xiàn)多接口的形式有很多種，例如：if..elseif.. 或 switch 或 動(dòng)態(tài)方法 (也就是TP的這種訪問(wèn)函數(shù)體的形式)

對(duì)于數(shù)據(jù)的輸出最好用json，json具有相當(dāng)強(qiáng)大的跨平臺(tái)性，市場(chǎng)上各大主流編程語(yǔ)言都支持json解析，json正在逐步取代xml，成為網(wǎng)絡(luò)數(shù)據(jù)的通用格式

接口安全，一定要增加接口驗(yàn)證。例如，客戶端和服務(wù)端針對(duì)不同接口統(tǒng)一做好加密方式，服務(wù)端在對(duì)于每次接口需要都要進(jìn)行驗(yàn)證。以保證防止接口被惡意刷新或黑客惡意調(diào)用，尤其是大型商業(yè)應(yīng)用。

對(duì)于線上的 API 必須保證所有接口正常且關(guān)閉所有的錯(cuò)誤信息 => error_reporting(0)，在輸出JSON 時(shí)，不能有任何其它輸出，否則，客戶端將解析數(shù)據(jù)失敗，直接 Crash！

開(kāi)發(fā) API 和 WEB 有一定的區(qū)別，如果是 WEB 的話，可能代碼出錯(cuò)了，不會(huì)導(dǎo)致特別嚴(yán)重的錯(cuò)誤，也許只是導(dǎo)致數(shù)據(jù)寫(xiě)入和查詢失敗，也許導(dǎo)致 WEB 的某個(gè)部分錯(cuò)位或亂碼。但如果是 API，直接 Crash！

做接口開(kāi)發(fā)，不建議使用框架開(kāi)發(fā)，原因概括起來(lái)有兩點(diǎn)（其實(shí)我有點(diǎn)冒風(fēng)險(xiǎn)的，本人也是 TPer 一枚，畢竟這是TP的官網(wǎng)）：

1）客戶端一般對(duì)服務(wù)端的響應(yīng)速度有極高要求，因此，使用最原生態(tài)的 PHP 完成接口開(kāi)發(fā)，是最高效的，假如用到了框架，還需要加載各種不需要多余的文件，就好比夏天穿了件冬天的衣服。試想，你在玩手機(jī)的時(shí)候，使用一個(gè)應(yīng)用隨便一個(gè)操作，等半天才有動(dòng)靜，你受的了嗎？

2）就是上面第4點(diǎn)提到的，框架對(duì)于WEB開(kāi)發(fā)，是件很幸福的事，但對(duì)于 API 而言，你實(shí)在不敢想象它會(huì)給你出什么岔子！最后你將痛苦不堪~~因?yàn)楹芏嗫蚣芏际菫?WEB 誕生的（我也很期待有一天能看到專(zhuān)門(mén)為開(kāi)發(fā) API 而生的框架或者擴(kuò)展）