Composer http in/out 節點的基本介紹
前言
如果還不知道什麼是 Composer 的朋友們，可以先參考這篇 DigiRunnerAPI組合與設計 。
該篇範例會用到之前介紹的節點，如果想深入了解這幾個節點的朋友，也可以參考以下幾篇：
此篇介紹避不掉一定用到，出現率 100% 的 http in 與 http out 節點，
並且它們是 Composer 組成 API 的關鍵兩個節點。
在使用 digiRunner 組合時，就預設會有，如下圖所示：
並根據在 digiRunner 選的方法 (method)，改變 http in 節點的 method。
例如：在 digiRunner 選擇 POST，則 http in 節點的 method 就為 POST。
接下來將會分享其運作機制、使用方法以及簡單範例。
一、基本介紹
http in 和 http out 是用於設置 HTTP 服務的兩個主要節點，分別用於接收 HTTP 請求和發送 HTTP 回應，
以下是 http in 節點設定介面說明：
(1) 如前言所提，預設將為 digiRunner 所選的方法，並如果要更改方法，還有以下預設選項供選擇：
(2) 可以選擇是否能接受檔案上傳。(只有選擇 POST 方法才會出現)
(3) 除了在 digiRunner 註冊的 API 路徑 (/hohlive/coco) 外，還能在 input box 自定義子路徑。
而關於子路徑設定後，如何讓外部打的到此 API，將另外放至 "進階教學篇"。
(4) 另外取名節點名稱，否則節點名稱默認為：[方法][API路徑]
(5) 編輯 Swagger 文檔給這支 API。(詳細 http in 的 Swagger 用法會另外開一篇來講解)
接下來是 http out 節點設定介面說明：
(1) 節點名稱。
(2) 回傳的 http status code，不填默認為 200。
(3) 回傳的標頭，可於左下角添加按鈕來增加標頭屬性。
二、節點參數與特性
http in 節點輸出參數：
msg.payload：GET 請求含有任何查詢字符串參數的物件。或者如果是 POST 或 PUT，則為 HTTP request body。
msg.req：HTTP request object。該物件包含以下幾個與請求訊息有關的屬性：
body - 傳入請求的正文。格式將取決于請求。
headers - 包含 HTTP 請求標頭的物件。
query - 包含任何查詢字符串參數的物件。
params - 包含任何路由參數的物件。
當節點將在配置的路徑上監聽特定類型的請求，例如 /user/:name。 使用命名參數 (name) 時，msg.req.params = { "name": "value" }。
cookies - 包含請求 cookie 的物件。
files - 如果節點啓用了文件上傳，則爲包含了上傳的文件的物件。
msg.res：HTTP 響應物件。此屬性不應直接使用；http out 節點記錄了如何響應請求。該屬性必須保留在傳遞給響應節點的消息上 (msg)。
http out 節點傳入參數：
msg.payload：響應的正文。
msg.statusCode：響應的狀態代碼，默認值：200。如果節點介面已設置，則以節點介面設置的為主。
msg.headers：響應的 HTTP 標頭。如果節點介面已設置，則以節點介面設置的為主。
msg.cookies：如果設置，則可用于設置或刪除cookie。
cookies 屬性必須是名稱/值對的物件。該值可以是使用默認選項設置 cookie 值的字符串，也可以是 options 物件。
下面的示例設置兩個 cookie - 一個名爲 name 的值爲 nick，另一個名爲 session 的值爲 1234，並且有效期設置爲 15 分鍾。
msg.cookies = {
name: 'nick',
session: {
value: '1234',
maxAge: 900000
}
}
其 session 物件有效的屬性包括：
domain - (字符串) cookies 的域名。
expires - (日期) GMT 標準時間的到期日。如果未指定或設置爲 0，則創建會話 cookie。
maxAge - (字符串) 相對于當前時間的到期日期（以毫秒爲單位）。
path - (字符串) cookies 的路徑。默認爲 /。
value - (字符串) cookies 使用的值。
要刪除 cookies，請將其 value 設置爲 null。
三、簡單範例
以下範例為請求氣象局提供的 API，並依據傳入參數取得全台有人或無人氣象站的資料：
在 http in 因為需要傳入參數，所以我們選擇了 POST 方法：
在 switch 節點中我們設定當 checkType 為 "someoneStation"，則去請求有人氣象站的資料，
checkType 為 "nooneStation"，則去請求無人氣象站的資料，
checkType 不為以上兩種，則進入錯誤處理流程。
在名稱為 Station 列表的 function 節點，我們取得需要的內容，然後放入 msg.payload 再回傳，
這樣 http out 才能回傳我們欲提供的資料至 response body。
而錯誤處理的部分，我們對 statusCode 賦予 400，表示 Bad request，並在 body 的部分提示"無此類型"。
回到 dgR 的 API 列表去測試 API，
在請求有人氣象站時，我們參數如下圖所示：
我們在 Composer 編輯器裡面，已能明確看到 debug 節點印出請求的 body 在 msg.payload：
回傳結果：
在請求無人氣象站時，我們參數如下圖所示：
回傳結果：
如果 checkType 不是以上兩種狀況，
則觸發錯誤處理：
可以看到如實的回傳 400 http status code 和提示訊息。
以上為製作 Composer API 的簡單範例。
註：
1. msg 在傳遞時，要注意 msg.res 屬性千萬不能消失，API 回傳時會需要此參數，不然會無法回應並過段時間 Composer 將判定超時，
並出現此錯誤訊息：
2. 根據協定，一個 API 流程請求時只能回應一次，所以當消息 (msg) 被分流時，有可能在回應時出現複數次，
如下圖流程所示：
此時在除錯介面就會出現警告：
四、結語
快速製作出一個 API，http in/out 節點將會是你的好幫手。
簡單介紹了基本用法和幾個常踩到的雷外還給自己挖了兩個坑，
一個是如何讓外部打到有 sub path 的 API 以及如何設定 http in 節點內的 swagger 文檔，
有空(?)會再找時間補滿這兩個坑。
五、參考文獻
(1) node-red 官方
(2) 自己
