WebApiBase RealNameSystem

URLoser404 8/15/2021 projects

# Web Api Base 實名制系統

# 前言

2019年12月，中國湖北武漢市發現不明原因肺炎群聚，沒有人想過這個病毒能持續延燒到至今，沒有人想過這個病毒能為人類史寫下一個新的篇章，沒有人想過這個病毒改變了全世界的衛生準則，這病毒便是大名鼎鼎的COVID-19。

事到如今，這個21世紀黑死病也即將在科學的力量下畫下尾聲，但這並不代表沒有其他病毒正在蓄勢待發，整個疫情中抵抗新冠肺炎的最佳盾牌便是實聯制系統，實聯制系統的出現，讓我們能夠控制新冠肺炎的災害範圍，這對台灣的防疫有極大的加持，也讓我們不用每天都心驚膽戰的出門，讓我們的生活更加安心。

台灣政府在這次疫情所使用的實聯制系統，是基於電信公司的"簡訊實聯制"。簡訊實聯制這個架構的方便之處在於可以直接透過傳送簡訊直接獲得聯絡資料，但弊端就是網路的接口較少，這次的主題便是想開發一套基於Web Api的實聯制系統，可以視作是原架構的新接口，也可以視為我們開發的新架構，能夠防範下一次大型疾病的發生便是我們最想要實現的目標。

# 核心 - Web Api 架構

# 實作構想

這次的Api考量到可能會有大量資料，決定使用SSMS搭配Visual C#來開發，此架構的特點在於可以高效且方便的進行大型系統開發，缺點便伺服器還境受限，只能把伺服器架在使用Windows系統的電腦上面、開發環境(Visual Sutdio)龐大等等，不過API的特性是能夠進行跨平台來進行實名制的動作，讓大家能以最簡單最方便的形式使用這套系統。

# 資料庫建構

開發Api的第一步便是開發資料庫，這次系統的資料會主要圍繞在聯絡資訊，和實聯制店家資料，實聯制方便的點便在於，資料內儲存的並非使用者的個人資料，如身分證字號、姓名、住址等等，而著重在使用者的聯絡資料，與實名制有著許多不同，詳細的差異可以參考下表。

	實名制	實聯制
目的	真實姓名制：便於日後疫調的即時性	實際聯絡制：能實際聯絡到各個對象
蒐集資料	真實姓名、連絡電話、身分證字號、地址等	姓名（可非真實姓名）、連絡電話

透過上方的構想，我們建立出了一個如下圖所示的資料庫，透過模現實情況，這個資料庫所欠缺的便是資安驗證系統，但由於這套系統還在實驗階段，所以我們並未對API進行加密與Token驗證等工作。 User資料表用以儲存使用者資料，包括電話、姓名(因可不為真實姓名，所以Allow NULL) Site資料表主要用以儲存實聯制店家資料，包括連絡電話、地址、店家名稱 User_Log資料表用以儲存使用者的足跡，主要包括時間、地點、以及使用者資料，是此次系統的核心

這次資料庫的規模並不是過於龐大，這或許也是實聯制的好處之一，但是靠慮到資料量可能會非常巨大，資料庫的正規化還是必須做好，避免大量資料造成伺服器負擔，但多人會因為覺得很麻煩而不去做的一件事，在這裡我提供一個我建立BCNF正規化所使用的準則:

避免一個資料表中有非不定值存在
每個資料表都必須有ID且ID為主鍵
關聯鍵其中一方必為主鍵

# 資料轉換

Api需要抓取資料庫裡的資料，但資料庫的資料形式(DataTable)並不可以直接轉換成Api一般回傳的資料形式(Json & XML)，但可以決定回傳形式後，由建立DTO(Data Transform Object)來當中繼的方式來轉換。

# 決定回傳資料形式(Json)

轉換的第一步便是決定Api方法的回傳資料樣式，我們使用了Json作為回傳資料的樣式，最終所統整出來後Api總共會有8個方法(methods)，十個方法的資料回傳分別如下:

# 使用者部分

新增使用者 POST

{
  "name" : "name",
  "phone" : "0987654321"
}

取得使用者資料 GET/id

//回傳資料
{
  "name" : "name",
  "user_phone" : "0987654321",
  "user_log":[
    {
      "date":"2021/06/08",
      "time":"13:24:15",
      "site":{
        "name" : "復興藝術展覽館" ,
        "phone" : "098754321",
        "address": "台南市內湖區中山路154號"
      }
    },
    {
      "date":"2021/08/15",
      "time":"09:25:32",
      "site":{
        "name" : "新美食創意雞排" ,
        "phone" : "098754321",
        "address": "台中市北屯區大明路26號"
      }
    } 
  ]
}

更改使用者資料 PUT

//上傳資料
{
    "id" : 1,
    "phone": "0987654321"
    "name" : "name"
}
//回傳資料
{
    "state" : "successful"
}

使用者個人上傳足跡 POST

//上傳資料
{
  "date" : "2021/01/01",
  "time" : "00:00:00",
  "phone": "0987654321",
  "site_name" : "復興藝術展覽館"
}
//回傳資料
{
  "state" : "successful"
}

# 店家部分

新增店家 POST

//上傳資料
{
  "name" : "name",
  "phone" : "0987654321",
  "address" : "somewhere"
}
//回傳資料
{
  "state" : "successful"
}

取得店家資料 GET/id

//回傳資料
{
  "id" : 1,
  "name" : "復興藝術展覽館",
  "phone" : "04876543215",
  "adress" : "台中市北屯區大明路26號"
}

更改店家資料 PUT

//上傳資料
{
  "id" : 1,
  "name" : "新美食創意雞排",
  "phone" : "04876543215",
  "adress" : "台中市北屯區大明路26號"
}
//回傳資料
{
  "state" : "successful"
}

店家統一上傳使用者足跡 POST

//上傳資料
{
  "id" : 1,
  "user_log":[
    {
      "date" : "2021/06/08",
      "time" : "13:24:15",
      "name" : "林文玉",
      "phone" : "0965117843"
    },
    {
      "date":"2021/08/15",
      "time":"09:25:32",
      "name" : "張富豪",
      "phone" : "0944818653"
    } 
  ]
}
//回傳資料
{
    "state" : "successful"
}

# 資料轉換物件

第二步便是要進行資料庫資料跟Json的轉換，雖然資料庫的資料不能夠直接轉換成Json，但可以透過物件(Object)來當作中繼，進而將資料庫的資料轉換成我們在上一章中所決定的Json格式，這能大幅的縮短呼叫資料庫的SQL語法，對整體的程式碼而言，簡潔了許多，需要?個的DTO如下:

# Api核心

第三步是組合資料，有了資料庫，還有根據Json格式所建立的DTO，便可以直接開始製作Api的主要元件，也就是Controller，有了Controller才能

# 成果

完成了Api的核心後，就可以輕鬆地根據使用情境來建立需要的接口，例如實聯制地點所需要的大型登錄機台，或是手機上的實聯制App，都可以透過我們剛剛製作的Api來快速的開發。

# 介面 - Win Form

# 介面 - Android App

# 心得

# 參考資料

聯合新聞網 - 為何不掃身分證就好？一圖看懂「實名制」、「實聯制」差異 (opens new window)