第二章 相關理論與技術背景
2.3 相關技術
2.3.4 Representational State Transfer
2.3.4 Representational State Transfer
REST(Representational State Transfer)，是 Roy Fielding 博士在 2000 年提 出來的一種軟體架構風格，相較於其他複雜的 SOAP、XML-RPC 更加簡潔
Rest 是一種設計風格，主要是從三個方面定義:[4,15]
1.使用直觀簡短的資源地址，來對資源傳輸與操作，即資源是透過 URL 指定。
2.傳輸的資源是 Web 接受與返回的網際網路媒體類型，如 JSON、XML 等。
3.對資源的操作對應 HTTP 協議所提供的 GET、POST、PUT、DELETE 方法。
REST API 是基於 HTTP 協定，使用 URL 來對資源作操作，實作 CRUD(Create、
Read、Update、Delete)對應於 HTTP 協議提供的 GET、PUT、POST、DELETE 四種 請求方法，由於前端跟後端往往是交付由不同人開發的，一個簡單易讀的 API 可 http://example/book 列出整組
資源
http://example/book/119 列出特定 資源
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第三章 系統架構
此章節描述本論文系統架構設計。首先從概觀的角度出發，講述隨境遊戲的特性，
再介紹系統架構的考量與設計目標，最後在介紹架構中各個主元件所負擔的功能。
3.1 系統設計考量與目標
由於隨境遊戲不像傳統遊戲是在固定地點遊玩，是深入現實生活環境中，以及 手機APP 的特性是需要時常即時的修正錯誤跟維護，因此整個系統設計上目的 是能具備易於維護、修改的特性。
整個系統設計分為前端和後端兩個部分，如圖 3.1，前端分成管理資料的 web 介面，以及用於體驗遊戲的手機 APP，後端主要分成應用程式介面 API、
主程式以及資料庫管理三個部分。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 3.1:系統架構概觀
手機端設計考量手機 APP 必須時常進行功能增減、除錯等的程式修改，由於 APP 是安裝在各個使用者手機中，要進行版本維護等工作，是較為困難的，且 改版過於頻繁會給使用者不佳的體驗，因此目的是盡量減低手機端 APP 的修改 機會。
在後端系統上，應用程式介面 Application Programming Interface，考量 前端有 web site 跟手機 APP 兩個部分，以及手機端 APP 不易維護的特性，在面 對前端的部分，要具有一致性，即 web site 跟手機 APP 使用的 API 是同一種設 計風格、思維，易於維護性，功能修改或是錯誤修正時，盡可能不需要修改到前 端應用程式。在程式邏輯運算上，減低每項對應到 API 功能運算間的耦合性，提 高程式碼的的可重用性，以減輕維護修改上的負擔。在資料庫管理上，程式邏輯 運算層不直接撰寫資料庫的操作，而是建立一個程式邏輯跟資料庫中間的中介，
目的是當資料庫有所更動時，程式邏輯層不需要隨之改變。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
上述是本論文系統設計的考量與想達成的目標，下面會開始對系統概觀的 描述和系統元件的設計概念。
3.2 系統架構概觀
本論文的系統採用模組化的設計思維，以高聚合、低耦合為設計原則，用以達到 程式碼易於維護即修改的特性，整個系統規劃採用 MVC 的架構，用以減輕系統 維護難度與頻繁更動的需求，由於 MVC 架構是 Controller 接收 View 的請求後，
轉道 Model 去進行程式邏輯運算，在經由 Model 返回給 View，而本論文系統為 了更確實的分層設計，實際上設計更接近 MVP 的架構，即 Model 返回透過 Controller 在給予到前端。
Figure 3.2:系統架構圖。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 3.2，為本論文系統的整體架構圖，分成三個主要部分前端、後端主程式 以及資料庫，以及兩個連接介面，前端與後端主程式的應用程式介面 API 是採用 REST 的設計風格，後端主程式與資料庫的溝通是採用 ORM 的方式。
3.3 系統主要元件介紹
圖 3.3，為本論文的系統主要架構流程，由前端、主程式、資料庫組成，前端分 成 Web Site 和手機 APP 兩個部分，Web Site 負責系統的管理維護，手機 APP 是 主要的遊戲操作，主程式是由 Controller、Service、Dao、Model 四個元件組成。
整個系統流程，是由前端發出請求經由 Controller 轉到對應的 Service，經過 Dao 向資料庫取得所需要的資料，在依序將結果返回前端。
Figure 3.3:系統元件流程圖。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
以下對主程式的四個元件作介紹。
Controller:負責前端與後端的溝通，實作應用程式介面(API)的部分，所有前端 與後端的資料傳遞都需要透過這個元件做處理，同時也包含著大多數的程式運算 邏輯。
Model:定義系統所需要的物件，即資料庫所對應的 TABLE。
Service:是程式的主邏輯，根據需求設計對應的服務。
Dao:主要負責跟資料庫的操作，將和資料庫操作有關的都撰寫在這個元件上，未 來資料庫有更換的話，只要對這一層作修改。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第四章 系統實作方法
此章節主要在描述本論文系統架構時做的細節，重點會從資料庫設計出發，藉由 Data Modeling 的方式，解釋如何從和使用者討論的抽象概念一步一步轉化成本 論文的程式系統，負責前後端溝通的 REST API 的設計方式，再帶入實作 MVC 架 構的程式的實作細節。
4.1 資料庫設計
從 USER STORY 討論開始，將預計 APP 的使用情境按照流程繪製出來，以確認想 法，然後按照 Data Modeling 的流程先從 USER STORY 中去提取實體，繪製 conceptual data model，如圖 4.1~4.3 所示，這個 APP 運作的主要流程有三項，
第一項是 USER 根據地點打卡，並且將打卡紀錄存入資料庫中，第二項是根據第 一項產生的打卡紀錄去計算出這個時間下的 KEEPER，並將每一期的 KEEPER 存入 資料庫中以供查詢使用，第三項是根據上述兩項 USER 產生的打卡紀錄、KEEPER 紀錄，根據設定好的徽章條件，去計算 USER 是否取得這些徽章。
藉由上述三項流程，可以歸納成三類，如圖 4.4，最基本的實體資料 USER、
PLACE、BADGE，屬於程式邏輯的動作狀態打卡、計算 KEEPER、計算徽章，以及根 據動作衍生出來的資料打卡紀錄、獲得徽章、KEEPER 紀錄，再來將上述實體結合 USER STORY 中的程式流程繪製 logical data model，將資料的細節表達出來，
包括所有實體的關係跟程式邏輯。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.1:APP 流程圖(打卡)。
Figure 4.2:APP 流程圖(獲得徽章)。
Figure 4.3:APP 流程圖(計算 Keeper)。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.4:流程分類。
Figure 4.5:Logical data model。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 4.5，是本論文系統程式的 logical data model，這個 Pervasive game APP 的主要核心是 USER 的打卡紀錄，像是 KEEPER 以及 USER 獲得的徽章都是經 由打卡紀錄所產生出來的，而為了提高程式效能在設計上，會把原本動態產生的 資料，實體化成資料庫中的 TABLE，像是 KEEPER 是由特定期間內的打卡紀錄產 生，產生這一期的 KEEPER 後，就存入另一個 TABLE，這樣要查詢過去歷史的 KEEPER 時就不需要再從打卡紀錄中提取出來，而另一個提升效能的例子是 USER 的徽章 紀錄，從流程上出發，徽章是由 USER 的打卡紀錄中去尋找是否符合獲得徽章的 條件，符合才授予 USER 徽章，這其中需要跨越多個 TABLE，像是打卡、USER、
PLACE、KEEPER、BADGE…等，由此可知計算 USER 是否取的該徽章是件需要大量 效能以及對資料庫存取的工作，因此將 USER 已經獲得的徽章額外建立 TABLE 做 存取，不做重複的計算工作已減輕後端 Server 的負擔。
而在 physical data model 的部分，由於採用了 Object Relational Mapping 的架構，TABLE 的建立是在透過程式中 MODEL 的部分去操作，且為了增加彈性以 及維護性不實際賦予 Table 與 Table 間的主從鍵值關係，即每張 Table 在資料庫 的層級都是各自獨立的，而圖 15 中的關係，則是藉由程式邏輯層再賦予 Table 間的關係，以 USER、PLACE、CHECKIN 這三張 TABLE 為例，在資料庫的層級，都 是互相獨立的，刪除任一筆資料皆不會對另外三張表有所影響，而要在 CHECKIN 建立打卡紀錄資料，是從 USER 以及 PLACE 取得相關欄位值，結合時間資訊存入 CHECKIN，如圖 4.6，也由於這個設計方式，在程式邏輯上要考量到表之間不會有 相依的關係，表與表的關係僅是查詢作用，即刪除一筆 USER 資料，必須不會對 程式造成錯誤。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
，
Figure 4.6:Check in 流程圖。
而在設計上第一層的實體，USER、PLACE、BADGE 是不被刪除的，而是採用狀 態管理的方式決定是否停用，並不實際刪除該筆資料，其他的動態資料以及歷史 紀錄，都是向第一層的實體進行查詢。
4.2 REST API 設計
這個章節是說明前端與後端溝通的應用程式介面 API 的設計，說明為何採用 REST 風格設計，以及實際設計的想法跟概念。
4.2.1 REST API 設計理念
應用程式介面（Application Programming Interface），是為了在系統不同組成 部分相互溝通時的接口，由於現今軟體系統規模越趨複雜，需要把複雜的系統依 照需求規劃分割成各個部分，為了降低系統各個部分的相依性，API 的設計就越 趨重要，好的 API 設計可以提高各模組的內聚性，降低彼此的耦合程度，用以提 高系統的維護跟擴充。
為了降低 API 的獨立性，以及避免網路所造成的錯誤，前端所設計的每個 動作，都只會對應的一個 URL，而不會是一組 URL 來完成動作。
‧
POST /app/user/{userid} 更新個人資料在傳遞資料上，傳統的 URL 會直接把變數名稱放在 URL 上，而採用 REST 設 計的 URL，不會直接看到變數名稱，隱藏了所傳遞資訊的意義，如表 4.2 所示。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Table 4.2:REST 風格 URL 與傳統 URL 的差異。
傳統 URL /app/place?placeid=01 REST API /app/place/01
以本系統中對於據點進行攻擊防禦的例子，表 4.3。attack 為 1 代表攻擊 0 代表防禦，另外兩個變數代表要攻擊的地點，以及是誰進行攻擊防禦的，可以看 到前者很明確的就能讓別人知道這個 URL 所代表的意義，而後者則可以把傳遞的 資訊隱藏起來，且也更為簡單易用。
Table 4.3:REST 風格 URL 與傳統 URL 差異(本論文例子)。
傳統 URL /app/attack?attack=1&placeid=2&userid=3 REST API /app/attack/1/2/3
4.3 MVC 實作
MVC 程式實作是採用 Spring Framework 撰寫 JAVA 程式，會由 View、Controller，
Model 三個面向來說明。
4.3.1 View
View 分成網頁端以及手機端兩個部分，網頁端是內鑲在 Spring 主程式中，透過 Controller 將對應的 URL 轉到相應的網頁，圖 47，瀏覽器對/user 作出請求，
後端 Controller 返回 USER 的頁面資料到前端瀏覽器顯示，圖 4.8。
後端 Controller 返回 USER 的頁面資料到前端瀏覽器顯示，圖 4.8。