本人第一次設(shè)計供給移動端的API，中間遇到些困惑，想咨詢下各位有經(jīng)驗的前輩，目前服務(wù)端使用的是Java：1.返回的參數(shù)對所有接口都統(tǒng)一化還是各個接口區(qū)分對待？我理解的統(tǒng)一化：{message:"XXX", code:"XXX", data:"不同接口的數(shù)據(jù)集"}我理解的區(qū)分化：{message:"XXX", code:"XXX", users:"用戶結(jié)果數(shù)據(jù)集"}、{message:"XXX", code:"XXX", reposities:"資源庫數(shù)據(jù)集"}2.看了github的API接口，較長的參數(shù)一般使用下劃線拼接，如：following_url，html_url字段?，F(xiàn)在服務(wù)端是Java語言，Java語言對參數(shù)的命名都是駝峰風(fēng)格，那么我返回的參數(shù)是按照駝峰設(shè)計呢還是類似于github的方式？3.以前是做Java支付交易系統(tǒng)的，時間都是YYYYMMDD、HHMMSS格式的，現(xiàn)在在做社交類型的系統(tǒng)，朋友推薦說使用時間戳或者格式化好的YYYYMMDD類型，所以請教下大家對返回的時間戳一般是怎么設(shè)計的？4.Token一般是放在后臺在Head里面返回客戶端，客戶端在請求時也是在放在Head里面吧？對于Token的設(shè)計，我想的是保存在數(shù)據(jù)庫里面，每次請求時通過查詢數(shù)據(jù)庫校驗是否正常，但這樣每次都查詢數(shù)據(jù)庫是很慢的，有沒有把token放在緩存里面（memcached或者redis）的做法？
5 回答
蕭十郎
TA貢獻1815條經(jīng)驗 獲得超13個贊
我覺得區(qū)分開來比較好。前端都用js解析json字符串，解析完之后，不存在的屬性就是
undefined，前端用戶可以判斷是否為undefined進行區(qū)分處理。我見過的一些接口就是成功的時候沒有error屬性，只在失敗的時候才有。這樣可以節(jié)省一些字節(jié)傳輸。命名我覺得比較隨便了，你跟前端同學(xué)溝通一下就行。只要保證統(tǒng)一即可，不要一會兒是下劃線一會又是駝峰
同意樓上意見，返回一個long類型的unix時間即可。這樣你獲取方便，下游的同學(xué)也方便轉(zhuǎn)換。要不然還得一直記著你的字符串格式。一旦出現(xiàn)其他同學(xué)接手就可能出現(xiàn)混亂。
token可以放到內(nèi)存里，這種用法比較多。定一個過期時間，一旦過期從內(nèi)存消除即可。當(dāng)請求較多，實時性要求較高而內(nèi)存也充裕的時候建議這樣。
猛跑小豬
TA貢獻1858條經(jīng)驗 獲得超8個贊
1、統(tǒng)一，減少與前端的溝通成本，也方便前端統(tǒng)一處理；
2、可以駝峰，也可以下劃線，只要內(nèi)部統(tǒng)一一種風(fēng)格就好了，記憶中Jackson序列化時有個設(shè)置可以讓駝峰格式轉(zhuǎn)換成下劃線格式的（反序列化時同理）；
3、用時間戳，由前端格式化時間顯示，方便同一接口在不同地方調(diào)用時可以顯示不同的時間格式；
4、Token一般有時效性，沒有必要放到數(shù)據(jù)庫里，一般用Memcached或Redis存儲并設(shè)置過期時間。
更新：Jackson的駝峰轉(zhuǎn)下劃線配置：
objectMapper.setPropertyNamingStrategy(PropertyNamingStrategy.CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES);
添加回答
舉報
0/150
提交
取消