這是俺整理公司新訓內容的第二篇文章，目標是對 Api, Restful Api, HTTP 等相關的知識點做個筆記，並用 .net Core 建立一個簡易的 Web Api 專案。

前言、基本觀念

我們在 上一篇 記錄了新訓第一天的 Git 操作筆記。接著在這篇，我們終於要進入 .net Core 啦！

目前的規劃是先從建立一個可以使用的、最簡單版本的 Web Api 服務開始，再將各個工具擴增進來。所以後續的文章應該都會以這篇的簡易 API 為基底繼續延伸下去（如果順利的話啦）

這篇文章的前半段會用來記錄一些使用或開發 API 常用到的相關知識，如果對 HTTP 的部分已經有點頭緒，或是迫不及待想直接動手用 .net Core 開 Api 服務的朋友們，可以直接跳到 正式開工 的部份。那麼，我們開始吧～

什麼是 API

我們在物件導向的 介面 時有稍微聊過所謂介面（Interface）的概念：「在兩個系統，或是兩個分層之間要介接的時候，只需要提供我這個功能的接口／介面給對方，就能讓對方知道如何使用」

API（Application Programming Interface）也是同樣的道理：

在不同的應用程式或服務（Application）之間，使用程式碼（Programming）的方式提供一組 介面（Interface），讓提供方和使用方可以藉由這組介面銜接起來。

API 最貼切的比喻就是我們在 封裝篇 也用過的販賣機：販賣機會提供不同飲料的按鈕，當我們選擇了其中一個按鈕按下、投了錢之後，對應的飲料就會掉下來。

對應回來就是：我們到了某個服務（販賣機），去拿我們想要的資料（飲料），所以呼叫了該服務的某支 API（按鈕）並且提供了一些該 API 要求的資料（投錢），最後 API 就會把我們想要的資料交給我們（飲料）

再用更實際的例子來說就像是：假設我們想要做一款可以查詢台北市的公車動態的 APP，於是我們到了提供公車動態的運輸資料服務 TDX (Transport Data eXchange) 去找我們想要的 API，過程中我們可能需要告訴服務我們要查的是台北市，最後服務就會將公車動態的資料交給我們。

關於 API 的部份，推薦可以先閱讀過 Huli 大大的這兩篇，將基本觀念說明的相當好懂且透徹：

• 從傳紙條輕鬆學習基本網路概念
• 從拉麵店的販賣機理解什麼是 API

另外，也推一下我在 CodingBar 看到的這篇 API 到底是什麼？ 用白話文帶你認識 和它所引用的影片：

當我們遇到比阿嬤的裹腳布還臭還長的類別時，常常會發生「需要一邊確認 Public 的 Function，但它用到的 Private Function 卻遠在天邊」，或是「SQL 字串／字串常數等等另外宣告在檔案最上端，導致瀏覽邏輯到一半的時候還要來回跳」的狀況。

在 上一篇 我們分享過用書籤的方式來記錄兩個地方來回飛躍，但如果是要互相比對或理解流程等等時候，就比不上分割視窗來的方便。

在 Visual Studio 用分割視窗的方式開啟不同的檔案，相信大家都已經駕輕就熟，尤其用過 Visual Studio 來進行 Merge 的朋友一定對這樣的排版不陌生。但是你知道就算對同一個檔案，也可以使用分割視窗來同時編輯兩個地方嗎？只需要動動滑鼠就可以囉！

這是俺整理公司新訓內容的第一篇文章，目標是整理 Git 相關的筆記。

• 前言、推薦資源
  • 什麼是 Git？
  • 什麼是分散式版本控制？
  • 先告訴 Git 我們是誰
• 建立一個新的儲存庫（Git Init）
• 把檔案加到 Git 的追蹤目標（Git Add）
• 提交變更（Git Commit）
  • Git Commit 的訊息該怎麼寫？
  • Git Commit 的時機？
  • Git Commit 和 Add 的 Combo 技
  • 加入 .gitignore 來忽略指定檔案
• 查詢 Commit 紀錄（Git Log）
• 查詢兩個 Commit 之間的差異（Git Diff）
• Git 的 HEAD 是什麼？
• Git Revert：讓我們往回走一步
• Git Reset：讓我們搭上時光機
• Git 的分支（Branch）是什麼？
  • 新建分支（branch）與切換分支（checkout）
  • Git Stash：讓我們快速存個檔
  • Git Merge：讓我們合併兩條分支吧
  • 什麼是衝突（Conflict）？
  • Git Rebase：讓我們移花接木
  • 我們現在有哪些分支（Git Branch）？要怎麼刪除分支？
  • 認識 Git 的斷頭（detached HEAD）
  • 關於 Git 的分支策略
• 什麼是 Git 的遠端儲存庫（Remote）？要怎麼把變更推送（Push）到遠端儲存庫？
• 要怎麼從 Git 的遠端儲存庫拿到變更？認識擷取（Fatch）、提取（Pull）
• 使用 Git Clone 直接把遠端儲存庫的 Repo 抓下來
• 認識 Git 的提取要求（pull request, PR）
• 小結
• 本系列文章
• 參考資料

前言、推薦資源

說來慚愧，前陣子 PTT 和臉書社團都有討論到相關科系畢業卻不會 Git 會不會太誇張，我正是畢業之後才開始用 Git 的那類人囧，相信像我一樣的人並不少，因此這個系列就決定從「新訓時學到的 Git 的基本操作」開始記錄。

開始之前先感謝公司前輩和完善的新手教學，還有第一天就先學 Git 的優良傳統。另外，也感謝相當多優秀的 Git 學習資源，說明得也更為詳細深入，想好好了解 Git 的朋友也可以逛逛，這邊就先推薦一波：

• 為你自己學 Git
  • 對新手非常友善。網站點進去後往下拉，可以看到大部分章節都能免費看，佛！
  • 最有價值的是裡面的各種狀況題。畢竟當你用 Git 不只需要基本操作的時候，呃，祝你好運
• 連猴子都能懂的 Git 入門指南
  • 從入門到進階篇跟過一次的話，基本操作就沒有問題了
  • 圖解讓人很好理解，而且在教學的實作部分會提供儲存庫讓你下載實作
• 黑暗執行緒的 Git 分類文章
  • 同場加映：黑暗執行緒的 Git 指令筆記
  • 黑大出品，品質保證
• Learn Git Branching
  • 用遊戲通關的方式認識 Git，對於一些分支的概念會很有幫助
• 30 天精通 Git 版本控管
• Pro Git

接下來我們就從認識 Git 開始吧！

什麼是 Git？

你發生過以下狀況嗎？

• 從沒做過版本控制，結果突然要改回前一版，不知所措
• 使用資料夾／壓縮檔板控
  • 20201201.rar, 20201215_v2.rar, 20201215_首頁.rar……
  • 空間越吃越兇，東西越來越雜，事情越想越不對勁，但是不敢刪除
  • 其實不知道每一份實際上改了哪裡，要復原某一段的時候要找半天，不如直接重寫一段
• 團隊合作／分組報告，各自負責一個區域，結果複製來複製去組不起來，不只需要看眼科，修 BUG 還比寫的時間還多
• 看到一段程式碼
  • 完全不知道為什麼要這樣寫
  • 或是氣到要死，抓不到戰犯

那麼，你很有可能需要 Git！

Git 是一套分散式的版本控制，就像是打電動時的存檔。讓我們可以在面臨重要選擇的時候存檔、打王之前存檔、打贏的時候也存個檔。當然，像是那種有多劇情多結局的遊戲，也可以針對不同路線各自存檔。

同時它也支援雲端存檔，你可以在電腦上存個檔，然後有網路的時候就丟上去雲端備份一下。而這個雲端備份是共用的，所以你可以跟朋友一起玩同一款遊戲，各自攻略不同的 BOSS，再把存檔和朋友互相交流交流，合成一個有兩份戰利品的存檔。

這些功能在 Git 有著聽起來比較厲害的名字，例如認可（Commit）、分支（Branch）、分散式、合併（Merge）等等。我們後續再慢慢了解它們。

長夜將至，我從今開始守望。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《冰與火之歌》守夜人誓詞

年初整理完物件導向系列後，休息（沉迷遊戲）了好一陣子，終於要繼續整理公司新訓的內容啦！

因為這個系列會是公司新訓時期的筆記整理，所以會是比較簡易的實作紀錄，並不會太過深入，需要的時候會用延伸閱讀的形式補充上去。如果看文的過程中覺得有什麼能夠補充的，也歡迎告訴我呦。

本系列預計會從 Git 的基本操作開始，簡單建立一個 Web Api 為主軸，逐步介紹相關的部份，例如簡單地引入套件、簡單地分層等等。基本方針就是直接抄襲 隔壁同事的部落格。

後續有更新的文章，就會整理到這篇目錄中。或是也可以從 菜雞新訓記 裡面做系列文的查詢。

那麼，就從第一篇：Git 入門這樣做 開始吧！

苦難終於告一段落了，開心到 PO 一篇來紀念一下！

接下來…… 就坐等血源詛咒上 PC 啦（等得到嗎？）

延伸閱讀

• 就是要逼你正面對決 《隻狼》如何用設計讓玩家展現勇氣？
• 《血源詛咒》如何善用內在動機讓玩家甘願受虐？

今天從同事們那邊學到了書籤這個方便功能，趁還記得的時候來做個紀錄。

那麼馬上就來操作一次：

使用 Ctrl K, Ctrl K 可以在指定的行號上加上一個「書籤」

隨著 2020 進到了 2021，菜雞與物件導向也推進到了五大原則結束，可以暫時告一段落了。

最初和朋友約好了要把公司新訓學到的東西做個整理（廣告一下他的部落格：Sian），只是沒想到因為太常發廢文偷懶，大半年才推進到物件導向的基礎而已，甚至占不到新訓內容的十分之一。希望 2021 能繼續推進，把這部份的坑給填一填，然後把前面的文章也重構一下，只是按照我的個性，可能又會忍不住開新的坑吧，哈哈。

至於物件導向相關的心得和紀錄，也就是這個系列，偶而有想到或是有所體悟的時候再發上來吧，暫時想先把前面隨手寫凌亂文章給整一整先。在這個十幾篇的短系列，記錄了從類別與物件開始，到耦合、內聚及五大原則，每個主題的心得。這邊稍微做個小整理：

類別、物件

• 物件就是用來表達「我們知道的某個東西」，物件導向是用物件彼此互動的方式來建立架構
• 類別去定義我們要的物件有什麼特徵、有什麼功能，再從類別中實例化（也就是根據設計圖產生）物件出來使用

建構式、多載

• 建構式用來在建立物件時就進行一些我們想要的操作，例如狗狗的毛色等等天生的東西，或是這個建立這個物件的必須素材
• 多載指的就是可以有很多個同樣名字的方法，各自去接不同的參數，讓同個目標的函式可以根據傳入的參數不同做不一樣的處理

在上一篇我們紀錄了依賴反轉原則，到此五大原則介紹完畢…是這樣嗎？太天真了！就像四天王總是五個人一樣，五大原則當然也有第六個！

今天的主角就是五大原則中Ｌ位的第一候補：最少知識原則，也被稱作迪米特法則。

最少知識原則 (Least Knowledge Principle)

只和直接的朋友溝通，不和陌生人說話

那麼所謂的朋友是什麼呢？就是指這個物件或方法有直接相關的物件啦。例如當我們使用一個方法時，這個方法應該只認識：

• 該方法所屬的類別
• 該方法所接收的參數
• 該方法中建立的類別
• 該方法所屬的類別所依賴的對象

除此之外對這個方法而言都是陌生人。什麼情況會遇到陌生人呢？有一個蠻常遇到的狀況就符合定義：當我們使用依賴對象的方法，該方法給了我們另一個類別時，我們就正在接觸毫無關係的陌生人。

在聊依賴反轉之前，先讓我們聊聊什麼是依賴，所謂的依賴就是一種「受到某個東西影響、牽制」的狀態。

例如說如果有個像我一樣的肥宅每天一定要來一片雞排才能療癒身心，那我就是依賴雞排；
同樣的，如果有個大叔不抽菸就會全身不舒服，就是對香菸有所依賴。

當有「必須要藉由某個人事物來達到目的」的狀況時，就是依賴。

而在程式設計裡面的概念也差不多，如果Ａ模組直接受到Ｂ模組的影響，我們就稱Ａ依賴了Ｂ，最明顯的狀況就是Ａ模組需要藉由Ｂ模組的實例來完成某個功能的時候。

例如「匯出報表」功能建立了一個「Excel 控制類別」的實例以建立檔案；
或是「會員查詢」功能建立了一個「DB 連線」的實例來進入資料庫取得會員資料

遇見這種「必須要藉由某個模組的實例來完成想要的動作」的狀況時，就是依賴。

依賴與耦合

我們在之前的 耦合篇 提過，如果模組和另一個模組之間有關連，那這兩者之間就耦合。以此來看，依賴就是一種耦合的關係，那麼，依賴是健康還是不健康的耦合呢？

現在讓我們用 多型篇 用過的「老闆徵工程師」的例子來舉例一下：現在有間小小公司，老闆請來了小明當工程師，並請他開工撰寫產品程式碼。

當「撰寫產品程式」對「工程師」直接依賴的時候，狀況可能是這樣的：

public Product Work()
{
    Ming programmer = new Ming();
    var product = programmer.Programming();
    return product;
}

過一陣子，老闆發現小明寫出來的東西似乎不太行，於是把小明趕走，另外請了小華。這時候因為「工程師」這個實作類別不一樣了，我們就必須要改一次程式碼：

public Product Work()
{
    Hua programmer = new Hua();
    var product = programmer.Programming();
    return product;
}

故事是這樣的——

Win10 工作列的合併設定有這些選項：

當選擇「一律、隱藏標籤」時，工作列上同樣的程式就會摺疊起來：

而「永不」和「當工作列滿時」則會將工作列展開：

好的，那麼像我個性這麼麻煩的人，如果覺得顯示名字很佔位置，可是又不想要摺疊之後按兩次才能打開我要的應用程式，偏偏又很愛開一整排 IDE 的話，有沒有什麼簡單的辦法不要讓圖示合併，但也不要顯示名字呢？

如果有個小工具，可以讓這些工作列的設定更彈性就好了，會有嗎？