新北市積穗國小國際文教中心文物導覽App開發紀實(5)--系統整體架構

有沒有可能一魚多吃?
因為  無論是Mobile App，Mobile version web，傳統web
其實 Data source 都是一樣的
若是寫死在App or Web page 當中
之後若有異動(例如換展)
或功能有增修
開發者會很慘
剛好之前和馬龍討論 Web API (簡單說  這是給程式看的  不是for人)的概念與實作
有興趣的可以看一看 台北市政府公開資料平台

靈機一動
若是這次專案就採用這樣的架構
就可以省去很多功夫
未來維護也比較有彈性
整個架構應該如下：

Data 提供者，撈取後端資料(無論是DB，XML，CSV)
基本上它會是以 HTTP Restful 實作
暫時只提供 HTTP GET method 提供外部系統呼叫
資料格式提供 json or xml 方式給外部系統

前端無論是 Mobile web , Trandidtional web , or Mobile App
Anyway，他們只要負責去呼叫這個 Web API
將取得的資料(JSON or XML)來做parse
各系統彈性就會很高
可以有自己各自的使用者介面與邏輯
擴充自己想要的功能等
其實骨子裡  他們的資料來源皆是一致的

舉例來說
有個API是提供查詢有ok認證的溫泉業者
那我可以做甚麼呢
其實他提供了 JSON 格式資料回傳
我今天可以做個App
結合LBS
例如我現在到北投某處想泡湯
App取得我的位置之後
呼叫該API
便可以在Google Map標出附近有哪些是經過認證的溫泉業者
還可以取得相關資訊和電話
這只是一個簡單的例子
國際文教中心系統的架構走向
我想應該朝這個方向規劃
只是   時間很趕.......................