後端工程師的第一堂課 (9) : API 應用方式
這是篇共 30 篇的後端領域入門系列文章，預計 1 -2 週新增 1 個新文章。
在後端領域有許多資源在告訴我們怎麼寫好 Python, Golang, Java, PHP … 等各種程式語言。但卻很少告訴我們怎麼學會 Web 後端領域 的知識。
希望你可以透過這篇文章，搭配你正熟悉中的某門任何程式語言，讓你順利入門 Web 後端 :)
【後端工程師的第一堂課】全系列: https://medium.com/@johnliutw/list/da301cc31b15
本篇的主軸會介紹一些實務上，常使用的 API 觀念和工具，主要會介紹三個常見的 API 架構方式:
- RESTful API ，現代已是主流的 API 開發方式
- WebService ，舊時代的 API 技術
- GraphQL，進行式的新時代 API 方式
並在最後，會跟大家介紹 PostMan 這個大家常用的 API 檢測工具。
RESTful API
RESTful API 的命名來源來自: Representational State Transfer + Ful，Full 則來自英文形容詞字義的命名方式。
RESTful 是一種 API 的設計架構方式，他把網頁最基本的四大功能: CRUD
- create 創建
- read 讀取
- update 更新
- delete 刪除
使用可讀性較高的方式，幫自己的 API 設計給外部用的入口，讓外部程式可以透過這些入口，執行針對不同資料源的這四項功能。
例如我們針對 comic 漫畫這個資料源設計 API，可以設計如同下方的 API 網址名稱:
- 獲取所有漫畫資料 www.comicking.com/comics
- 獲取特定漫畫資料 www.comicking.com/comic/1
- 新增漫畫資料 www.comicking.com/comic
- 更新特定漫畫資料 www.comicking.com/comic/1
- 刪除特定漫畫資料 www.comicking.com/comic/1
我們可以觀察到，上面的網址，總共有三種:
www.comicking.com/comics
www.comicking.com/comic
www.comicking.com/comic/1
而其中，www.comicking.com/comic/1 這個網址要達成三種功能。
想要做到這樣的技術設計，我們必須使用前一篇所學到的 HTTP Method 去分隔。例如針對 獲取特定漫畫 這件事，使用 GET 這個 Method，更新特定漫畫資料使用 POST，或是其他方法像是 PUT ，而最後 刪除特定漫畫資料，則能使用 DELETE 這個方法。
另外，我們前篇有提到，新增資料時，會慣用 POST 方法傳遞資料，
所以上述網址加上使用的 HTTP Method ，會變成:
GET 獲取所有漫畫資料 www.comicking.com/comics
GET 獲取特定漫畫資料 www.comicking.com/comic/1
POST 新增漫畫資料 www.comicking.com/comic
PUT 更新特定漫畫資料 www.comicking.com/comic/1
DELETE 刪除特定漫畫資料 www.comicking.com/comic/1
而 1 呢，其實通常指的就是某本 comic 資料的 ID 啦～
這樣有更了解了嗎？
WebService
WebService 是一些較早期發展軟體，最常使用的資料交換方法。其 API 位址會長的像如此: http://invoice.com.tw/InvoiceMultiWeb/InvoiceAPI?wsdl
你會發現，網址的最後有 wsdl 的參數，這個參數可以當作一種 API 模式的類型描述，通常指的是，當我們網址列貼上這個位置後，會看到如下的畫面:
好，這是一個非常可怕的 XML 格式頁面，描述了這個 Web Service 有哪些功能可以使用，以及資料輸入輸出的說明。
實際的使用方式，並不像我這幾天一直討論的，透過 GET、 POST 去傳遞資料，而是要透過不同程式語言的第三方套件，或是原生語法，去 取得 並建立 對方寫好的程式碼，再去執行它。
讀者們有注意到差別嗎？我們來看看簡單的下圖:
如果是 WebService ，我們得要在自己的網站產生一個 模塊，才能夠去執行它，來傳遞資料，而這是非常費工夫和效能的做法。
因此現代化的資料交換方式，就不再優先考慮此方法，不過因為很多大型軟體商，如 SAP ，有些舊的功能所開出的資料交換方式，仍是 Web Service 為主，所以還是要有一定的理解程度喔！
GraphQL
GraphQL 是 Meta ( 前 Facebook) 在 2015 年所公布的一種資料交換方式，其特點是，讓取用資料端，自己定義資料的樣貌，是一種相較傳統的 API 方式，特別不同的方式。
我們先看看一個 GraphQL 的實際運作樣貌為合:
我們可以看到，在圖片的上半段，代表的是我們想要取用的資料欄位，而下半部則就是伺服器所回傳的資料。可以看到，假設取用端知道 User 有哪些欄位，就可以自己抓取自己想要的資料去做組合。
而為什麼會有這樣的方式興起呢？
主要原因是因為現行的網頁技術越來越複雜，且有越來越多的商業流程數位化，導致資料的複雜程度倍增。因此利用這樣的方式，在提前定義好資料源的 schema，也就是整體的資料框架樣貌後，就可以不用依賴負責伺服器端的工程師，來幫忙產生自己想要的資料!
PostMan
PostMan 是一款非常方便的 API 測試工具，他最潮的地方是，本來只是chrome 上一個 extension，結果用的人越來越多，用用用到後來就推出軟體了…
他為什麼好用呢？筆者列出幾個最重要的優點:
- 可以針對不同程式語言，建構資料傳遞的程式碼模塊
例如，下面是要串接 Dog API 產出的不同語言版本程式碼
Python
PHP
2. 提供 JSON、XML、HTML、Text 等等資料傳遞的不同格式
3. 可直接導入特定的文件格式，快速產出測試用的 API
4. 可以搭配不同專案，儲存不同的 API 位址，並設計自動且結構化的測試流程。
如果使用者願意付錢錢，也能有快速產生 API 文件這種超棒的功能喔 XDD
另外在 PostMan 裡有些技術名詞，對於新手來說，可能需要特別了解一下:
- Request: 指的是 我對API要資料 這個動作，裡面會有 Headers、body 等不同類型的欄位
- Headers: API 技術上會用到的資料常放在這，例如檢核使用者身份用的授權相關資料
- Body: 資料內容，通常指的是實務上在傳遞的資料，像是使用者填寫的貼文內容等等
- Response: API 接受我們給他的資料後的回應。同時也會有 body 和headers，概念同 Request
