先簡(jiǎn)單點(diǎn)的，要會(huì)php的一些基本的語(yǔ)法。。先建一個(gè)test.php , 賦值數(shù)組： $return = array( 'id' = '1', 'name' = 'test', ) echo json_encode($return); //直接輸出~嗯，這個(gè)是json格式返回的數(shù)據(jù) app端調(diào)用test.php文件，能獲取數(shù)據(jù)。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：空間域名、網(wǎng)絡(luò)空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、孟連網(wǎng)站維護(hù)、網(wǎng)站推廣。
PHP開發(fā)APP接口需要注意下面問(wèn)題：
1.制定規(guī)范
開發(fā)前一定要定好一個(gè)規(guī)范，比如要定好數(shù)據(jù)返回的通用參數(shù)和格式。關(guān)于數(shù)據(jù)格式，用的比較多的有xml和json，我建議用json，因?yàn)閖son比xml的好處更多。
2.精簡(jiǎn)的返回?cái)?shù)據(jù)
接口數(shù)據(jù)因符合需要什么返回什么的原則，比如要查詢某個(gè)用戶的余額和注冊(cè)時(shí)間，網(wǎng)頁(yè)里面的做法可能是select * from user where
uid=1，但是接口一定要select balance,regtime from user where
uid=1。因?yàn)榻涌诜祷財(cái)?shù)據(jù)是要有開銷的，要流量的，能少返回?cái)?shù)據(jù)就盡量少返回，這樣可以大大的提高性能。
3.數(shù)據(jù)類型要嚴(yán)格
要注意數(shù)據(jù)的類型，整數(shù)類型的數(shù)據(jù)一定要轉(zhuǎn)為int，因?yàn)閍pp客戶端開發(fā)的java、object-c語(yǔ)言對(duì)數(shù)據(jù)類型比較嚴(yán)格，類型不對(duì)會(huì)照成app閃退。
4.要寫接口文檔
一定要寫好接口文檔，并按照模塊寫，而且還要書寫規(guī)范，最好的格式是：
接口請(qǐng)求地址;請(qǐng)求參數(shù)(包括參數(shù)名、類型、是否必填);測(cè)試參數(shù)舉例;返回參數(shù)(參數(shù)名，并注明每個(gè)參數(shù)的含義)。
這樣哪怕以后項(xiàng)目很大，以不會(huì)照成維護(hù)困難的問(wèn)題。
5.保證代碼正確性
要驗(yàn)證保證代碼正確無(wú)誤，而且生成環(huán)境中要屏蔽掉錯(cuò)誤，避免頭部有額外的輸出，照成返回的json等數(shù)據(jù)解析失敗而導(dǎo)致app閃退等。
6.要優(yōu)化代碼的性能
app要求響應(yīng)迅速，這樣才能給用戶比較好的體驗(yàn)感。所以移動(dòng)接口端在處理業(yè)務(wù)邏輯的時(shí)候，要避免不要執(zhí)行太復(fù)雜的sql語(yǔ)句，或者含有大量的循環(huán)，能做成緩存的盡量做緩存，比如將首頁(yè)的熱點(diǎn)模塊信息可以存到redis緩存中。在不考慮網(wǎng)速的情況下，比較理想的接口響應(yīng)時(shí)間應(yīng)該是200毫秒以內(nèi)。
7.不要隨意更改舊接口
app不像網(wǎng)頁(yè)，app一旦發(fā)布，有人使用之后，接口就不要亂修改了。以后升級(jí)也是，修改要在保證接口原有結(jié)構(gòu)之上進(jìn)行額外的擴(kuò)展，否則會(huì)導(dǎo)致調(diào)用舊版接口的app出現(xiàn)bug。
8. 注意接口的安全
安全高于一切，必須要保證接口的安全。電話號(hào)碼等敏感信息在傳輸?shù)倪^(guò)程中一定要加密，否則可能會(huì)被別人抓包到。拿取用戶信息的接口一定要驗(yàn)證權(quán)限，以防止接口被惡意調(diào)用，泄密用戶信息，甚至篡改信息。
都一樣的 只是由于app不是瀏覽器不能正常使用cookie所以不支持session認(rèn)證 在做app接口的時(shí)候一般都會(huì)使用自己定義的token來(lái)認(rèn)證 其他的都是一致的
JSONXML
XML: 是一種標(biāo)記語(yǔ)言，設(shè)計(jì)的宗旨是傳輸數(shù)據(jù)
JSON： 輕量級(jí)的數(shù)據(jù)交換格式
APP接口主要是用JSON輸出格式
APP接口輸出格式三要素：
1. code:：錯(cuò)誤碼
2. msg：錯(cuò)誤碼對(duì)應(yīng)的描述
3. data：接口返回的數(shù)據(jù)
誰(shuí)有權(quán)限調(diào)用APP接口，客戶端需要帶著憑證來(lái)調(diào)用APP接口
JWT的原理：
服務(wù)端認(rèn)證之后，生成一個(gè)JSON對(duì)象，返回給用戶。后續(xù)客戶端所有請(qǐng)求都會(huì)帶上這個(gè)JSON對(duì)象。服務(wù)端依靠這個(gè)JSON對(duì)象來(lái)認(rèn)定用戶身份。
組成: Header, Payload, Signature
1. Header
說(shuō)一下我是什么
header通常包含了兩部分：類型和加密算法
{
"alg": "HS256",
"typ": "JWT"
}
header需要經(jīng)過(guò)Base64Url編碼后作為IWT的第一部分。
2. Payload
payload包含了claim, 三種類型reserved, public, private
reserved這些claim是JWT預(yù)先定義的，不強(qiáng)制使用，常用的有：
1). iss: 簽發(fā)者
2). exp: 過(guò)期的時(shí)間戳
3). sub: 面向的用戶
4). aud: 接收方
5). iat: 簽發(fā)時(shí)間
{
"sub":? "1234567890",
"name":? "John Doe",
"admin": true
}
payload需要經(jīng)過(guò)Base64Url編碼后作為JWT的第二部分。
3. Signature
創(chuàng)建簽名使用編碼后的header和payload以及一個(gè)密匙，使用header中指定的簽名算法進(jìn)行簽名
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
簽名是在服務(wù)端進(jìn)行的，客戶端并不知道，所以是安全的。
重慶分公司
重慶分公司
