第二，誠然2020年3、4月可以做出比較完整的版本，但其實我們的拘束力結構，就是院長打算在10月有一個對外的公開宣示，說全國最大登山平台上線之類的，這個時候我們必須已經有一些東西讓大家可以用，用了再建議更多的，這個非常好，我們也瞭解到大家需要時間實作，但是並不能說我們什麼都沒有，就問大家說這個要不要、好不好等等。
按照院長在上次會議的發言，就是說「早餐店不應該去問人家要不要荷包蛋，而是要問一顆蛋或者是兩顆蛋」，因此在2019年10月要把第一顆荷包蛋做好，這個是政治架構。看宗諭要不要補充？
承襲上次會前會的脈絡，假設2019年10月就要把這個整合做到一個程度，大家會實際上碰到的，包含行政上跟技術上的挑戰，是不是可以先有一個對齊。
行政上，我先講一個實際上跟院長及部長們提到的概念，我們中央的機關，也就是各部會，只要部長同意，任何100萬以下的招標都可以比照10萬以下的招標，也就是沒有工程會或者是其他還要敘明理由等等，只要部長或者是主委簽了，95萬就可以當作9萬的採購來辦理，這個意思是可以省去一個月的行政程序，這個是第一件事。
但是接下來當然有兩個問題：
第一個是我們去做各位現在手上維護的平台，API的整合讓它能夠做一個讀寫的介面，第一個是95萬是否足夠？第二個一個月內可以爭取到，對每一條線95萬，這樣子有沒有可能在2019年10月就把這樣的東西上線，不管API長什麼樣子？這個是時程跟金額上要詢問的問題。這是第一件事。
第二，假設大家覺得現在正在維護的網站，沒有辦法用這樣子很像急行軍之類的方法來改造（Plan A），那就是考慮第二個狀態（Plan B），也就是有沒有可能大家現在既有的網站，對於我們在國發會特定的機房過來的一些IP，保留現有的路徑，就不要再去改版了，接下來一年只要從這個IP過來的，本來現在是長什麼樣子就是什麼，可以加一些新功能，但是這一些IP過來的，就會看到舊版的網站。
看到的時候不要有一些測試是不是人類的這一種captcha東西，這一些機器人，這個是代操，也就是代使用者操作你們的網站，這個要如何跟前端整合，這個API會要求新的廠商，如果plan A走通的話，我們會要求把這一段，不但是開放原始碼、API及文件，以後是可以合併進去的，而且也會希望在機器人代操作的設定上，同樣也跟剛剛要求在90萬之內、一個月之內完成。
所以大概對於每一個我們後端要接的網站會要請各位做這樣的評估，也請我們的公務同仁評估一下，假定跟錢、時程，廠商們覺得沒有問題或者是有問題找到備案的話，在行政程序上有沒有什麼我們沒有考慮到的，讓我們知道。看葉寧有沒有要補充的。
不是，如果database願意有一個view分享出來的話，我們只要看那一個view，如果view不分享出來，甚至只要保障網站介面不要改，我們就砍站、寫機器人，這樣什麼都不用改，其實你只要答應不改就可以了，這是最低的要求，這個是plan B；如果你願意寫API，當然資料庫開一個view或者是寫一層都是可以的。
我綜整一下我聽到的，Plan A是可行，但是你們同時有別人的客人點早餐，所以其實年底是比較忙的，團隊要去煎蘿蔔糕之類的。
但是到了明年，如果比較緩過氣來，經費也充裕的話，對於Plan A好好做出來，這個也是支持的。也許Plan B的情況，也許我們在這個系統裡面，請您提供兩件事，一個是從這個IP網段來的，就不要改介面，甚至你給我們一個特別的path，這個路徑是只有這個IP可以來，就是一直運行舊版程式，你知道我的意思嗎？這個並不是一定的，而是等你有空的時候，你再把它弄回來。
這個一定可以做，因為這個是不做什麼，不是讓你做什麼。Plan B只是不要對那個路徑更版，這個是第一件事。
第二件事，我們這邊會請現在的這一個暫時廠商，就是快速煎蛋的廠商，把這個東西盡可能整理成API的文件，自己省掉一道API的工序，用PMP或者是最好的方法來確保它的完整性、資安、API管理等等，我們之後就放到Plan B來進行，我們切成先後兩個來做，這個很清楚。
看公務同仁有沒有要補充的？
前端會對這一台綜整的機器作業，由它來連結這一些後端。
這個前端會長成什麼樣子，這是大家可以一起討論的，這是協作會議的標的。
但是它的功能怎麼樣，這是我們目前現在各位的後端所能夠做的功能，理論上在你們本來的網站上可以做到，在這個整合的地方就應該要可以做到，概念就是這樣。
當然如果有人很想做前端整合網，因為95萬之內就免評比，如果在場有人很有意願做的話，這也是可以討論的。
那是兩個100萬，前端100萬，然後這一條線再100萬。
不會，這是兩個標啊，真的啦！
這是兩個標，不是開玩笑的，因為它的工項不一樣，互相也沒有依存關係，你先寫哪一個、然後再寫哪一個絕無差別，工程會不能找你麻煩。
是，這個沒有問題，我們寫意見書給你。
所以你的偏好是由別的⋯⋯但是審計部是整個查，這根本沒有差別。
我們這邊可以先做兩個處理：
第一，也許我們先新上線的這個，我們叫做「一站式服務網」，跟現行「整合平台」有一個最大的不同，整合平台基本上是我們所說的出口網站——反正是進去之後又出去的網站——這個大家都非常清楚。
「一站式服務」是一進去不用點開任何網頁了，在這個網站辦好，所以第一個招標工項的大標題不一樣。
第二個是我們把網址弄到不一樣，我們在封閉測試的時候，也就是剛剛所講的一些先行者們，願意山屋還沒有完全蓋好就來爬了，我們給他一個網址，而且網域也不會在你的署底下，所以標題不一樣、工項不一樣、網址也不一樣，這樣子如果審計部還有一些疑慮的話，那沒有關係，我們也是可以寫一些意見書出來。
對，我也可以用廠商身分回答，所謂「政委自帶廠商」（笑）。
先回答一下，這個流程跟我們之前做報稅軟體還滿像的，只是報稅軟體不用抽籤而已，大家都得繳稅。
基本上這個狀態就看是Plan A或者是B，其實Plan A的情況，你可以想成你的使用者沒有辦法操作瀏覽器，必須要是像類似google這一些，也就是純粹用機器對機器的方法來進行溝通，這樣子通常最簡單的方法是你把自己的架構，我不知道你用什麼技術，像如果是「ASP.NET」，就可以生出本來服務的web API出來，現在也已經可以生OAS 3的規格。
早期一點的話，可能用的是swagger或者是Apiary，你等於是提供一個現行功能機器可讀的文件，轉成新版OAS3而已，重點是結構化的文件工作。
這看你網站的設計，如果你的網站設計已經是前後分離設計，你在前面是已經用了React、Vue、Angular這些東西的話，你本來就有一個接到前端的那一些地方，只是你可以隨便改，而且沒有文件說明而已，這樣在Plan A裡面，只要生出API文件，現在國發會全部都用OAS 3了，也沒有什麼別的選擇，雖然我自己比較喜歡另外一個API Blueprint，但總之大家都用OAS 3了，假設本來網站就有RESTful的能力的話。
第二個方法是，你本來前後端都寫在一起，本來沒有前端的程式庫，而是後端每個頁面重新畫一張HTML出來，那如果走Plan A出來，就要畫結構化資料出來。這個有兩個方法：一個是在HTML裡面嵌像JSON-LD的這種東西，反正是有機器可讀的部分跟人可讀的部分，這個是常見的。
另外一個是給我一個endpoint，像我們逐字稿的網站，大家都知道當政委之後，開了快1,000張場合，還有跟4,000多人，講了20萬句話，裡面每一場會議，我們處理所有的從一開始我們去討論救災的網站，救災的網站我們在進行討論的時候，其實我們也是從跟廠商的對話開始，在這個對話的過程中，每一個人都可以看到每個人到底講了什麼東西之類的。
在這個過程中，我們有一個給前端看的部分，網站架構其實並沒有API可言，就是把這一場對話畫成HTML，然後給使用者，把它顯示出來；但當時還有雲辦的時候，是在雲辦開的，當然大家都一定程度匿名化，我們知道誰是NEC，誰是中華電信，沒有姓名。
但如果現在要做一個像剛剛Plan A的東西，在 網址 後面加一個「.an」，忽然間包含可輸入部分、可輸出部分等等，總之就會給你一個XML檔。
所以要看你目前網站的架構，如果可以有一個XML或者JSON額外的endpoint，這個是一個做法，你生HTML可以嵌結構化資料進去，這是一種做法，或者你的前端本來就是用前端框架，把你的API寫好文件，也是一種做法，Plan A目前大概三種。
當然有很多其他比較尖端的，像GraphQL，但是這個我們就不講了。這樣有大概說明了嗎？
當然，本來就會跟臺銀，就是透過它的API，就是瀏覽器忽然彈出視窗或內嵌，然後回一個訊息碼給你，一定是長這樣？
這邊也是一樣。我們從web API的角度來看，你到這個情況下，然後給我一個payment required，這也是一個status code，然後你給我一個location，然後一個call back，或者一個web的網址，反正這一些OAS 3都有，所以如果是API的導向設計，這個節奏，OAS 3是可以描繪的，Swagger還不一定有辦法。看展銘要不要補充一下？
在這個網站過來的話，可以有兩個選擇，一個是立即幫他變成會員，一個是產生另外一個會員，也就是中間的轉銜期，就有點像Plan B，有另外一個伺服器來幫你預先註冊會員的功能，這個完全是看你自己寫，還是別人寫，如果別人寫，勢必要走到Plan B的解決方案來做，如果是你自己寫，當然有所選擇。
這個問題是所有廠商都會需要面對的。營建署的廠商有沒有什麼問題？沒有的話，就正式進入林務局這邊，像公務同仁在採購上有沒有問題，或者行政作業上有沒有什麼問題，還有廠商在資訊技術上有沒有什麼問題。
我們現在看起來是10月15日，你們抓10月15日，當然10月1日前端必須要開始測，也就是前端雖然大家都橋接上了，但是那個使用者體驗，像我們所說的拉皮必須要真的接上才可以，所以這個工項當然趕一點，一個禮拜也做完了，所以大家要有10月初有一個雛形版本的想法，但是如果真的讓Alpha tester可以用的話，大概是10月中左右。
OK。
不過我想先釐清一下，我聽到的是，大家可以客製化在不同的區需要填什麼欄位才可以進入，但是他的控制權是多到可以改變一個同名欄位的資料結構，還是其實只是不同欄位，有一點像抽換的方式來進行，這兩個是很不一樣的，同名欄位資料結構是可以修改的，或者是enum，我這邊1、2、3，他那邊4、5、6的話，當然我們在API的設計上會碰到一些挑戰。
不好意思，我先確定我有沒有聽懂，所以這個是類似資料建模的發現，當他發現你這個欄位有所更動的時候，並不會回溯到前面的申請，而是從你改了這個欄位變成多一個欄位要必填的時候那一刻開始，以後要填的人要填，前面的人在資料庫裡面是空的？
如果本來必填，後來發現沒有意義想拿掉，但是舊的沒有消失，等於新的不填、是隱藏起來，所以在資料模式上是不斷累加，只是有一些會藏起來而已。
這樣當然是滿容易處理，因為這樣聽起來像欄位名稱是地方保護區會有一個單一的代碼，所以自己加的欄位可能是它的代碼01-F01、F02，無論如何是累加，不會利用那個欄位編號，這樣的話，其實不管是走Plan A或者是Plan B，這個是非常容易處理，只要保證剛剛講的是不會回溯適用，不會一個現在叫做「行程目的」的東西，你用這個編號，然後莫名其妙改一個名字等等，這一種API inconsistency的情況不要發生。
這樣的話，其實只要保持繼續同樣的做法，我想外部API廠商當然可以來解析你的模型，因為對他來講，就是要使用者填一些欄位，這個當然是ok的。
