爬虫完成後没发出通知，就像是黯然销魂饭少了洋葱

为什麽通知很重要？

1. 在爬虫的运作完全自动化的状态下你需要透过接收通知，知道爬虫执行完毕
2. 通知的内容要简述这次爬虫的状况，因为实际上使用者只有在要报告或是写文章的时候才会去 Google Sheets 看爬虫的详细数据，平常他只需要知道爬虫有没有稳定执行就好

在通知这个部分我选择使用 LINE Notify 作为范例，你在了解逻辑後也可以自己改为用 Slack、Wechat、Messager... 等通讯软件来通知喔

今日目标

1. 取得 LINE Notify 权杖

2. 使用 POSTMAN 测试 LINE Notify

2.1 为什麽要先用 POSTMAN 测试 LINE Notify 呢？
2.2 用 POSTMAN 发出 LINE 的讯息
2.3 透过 POSTMAN 传送错误参数来了解 HTTP状态码的意思

1. 取得 LINE Notify 权杖

1. 请以 LINE 帐号登入 LINE Notify，登入後选择 个人页面
   
2. 为了要获得控制 LINE Notify 发讯息的权限，我们要 发行权杖
   
3. 在发行权杖的弹窗中，权杖名称请填写与功能相关的名称，接收通知的聊天室可选择 1对1、任意聊天室 这两种，确认无误後按 发行
   
4. 接着我们要将这组权杖(Token) 复制 下来
   
5. 关闭弹窗後能看到 已连动的服务中 有我们刚刚新增的服务
   
6. 同时你收到 LINE Notify 帐号启用权杖的讯息
   
7. 将发行的权杖(Token)加入 .env 环境档，在明天的教学会使用到

   .env.exmaple

   #放LINE Notify申请的权杖
   LINE_TOKEN='XXXXXX'
   

2. 使用 POSTMAN 测试 LINE Notify

2.1 为什麽要先用 POSTMAN 测试 LINE Notify 呢？

说明这个问题之前，我们先来探讨为什麽 POSTMAN 会这麽被工程师推崇，在这我归纳成以下几点：

1. 对 後端工程师 而言，可以向合作夥伴证明自己写的 api 没有在唬烂，真的可以 work
2. 对 前端工程师、App工程师、有使用 api 需求的人 来说，能在串接 api 前先用 POSTMAN 确认这些 api 真的可以 work
3. 有了这个工具作辅助，我们就能将前後端责任归属的很清楚。ex：如果 POSTMAN 上面可以正常 work，那前端就要去思考自己 api 哪里没串好
4. 工具操作难度极低，只需要对网路的世界有基础的认知就能快速上手

所以我们先用 POSTMAN 测试 LINE Notify 的理由是：

1. 确保 LINE Notify api 执行所需的 Request 参数、Respone 的结果与说明书一致（这点非常重要，因为我看过很多 api 回传的结构跟说明书完全不一样）
2. 在一行程序都不用写的状态下测试所有的可能性
3. 在 POSTMAN 验证後就能专心写程序，因为如果程序无法发出 LINE 的通知一定是自己的问题

补充：

• POSTMAN 在工程师的世界中素有 API测试神器之称，如果你对 POSTMAN 一无所知的话你可以先透过这篇文章了解一下他是做什麽的
• 他可以直接用 Gmail帐号登入在网页使用，也能下载桌面版 App，相同帐号的操作记录在两边都会同步

2.2 用 POSTMAN 发出 LINE 的讯息

1. 设定 Request 的参数
   • URL：https://notify-api.line.me/api/notify
   • Method：POST
   • Authorization：
     • TYPE：Bearer Token
     • Token：填入你刚刚在 LINE Notify 申请的权杖

     

   • Body：
     • form-data：

       key	value	DESCRIPTION
       message	来自宝宝的爬虫通知	纯文字(必填)
       stickerPackageId	2	贴图的PackageId
       stickerId	144	贴图的Id
       imageFile	icon.png	电脑上的图片档

     
     DESCRIPTION 是我对参数描述，实作上可以不避填
     如果你想深入的了解可以参考官方文件

2. 完成 Request 参数填写後按下 Send 发出 LINE 讯息
   • 看到 Response 的结果，status 为 200 代表传送成功
     
   • 在发行权杖的聊天室中，看到 POSTMAN 传送的 讯息、贴图、图片
     

2.3 透过 POSTMAN 传送错误参数来了解 HTTP状态码的意思

我们刚刚在 POSTMAN 的 Response 看到 HTTP状态码为 200，接下来我们故意做一些错误测试来看看会有什麽样的 Response

请注意并不是每只 api Response data 中的 status 都等於 HTTP状态码，只是 LINE Notify 刚好是依照这个逻辑显示，我们可以用它来帮助我们对 HTTP状态码的了解

1. 不填写 LINE Notify 的权杖
   • HTTP状态码为 401，代表需要授权才能使用
     
2. 在 Body 中不填写 message 的参数
   • HTTP状态码为 400，意味服务器收到无效的语法
     

透过上面的范例回传的资讯，我们可以了解到不同 HTTP状态码的意思：200 代表成功、400可能是参数错误、401是没有授权，当然 HTTP状态码不只这些，如果你想更深入的了解可以参考这篇文章

参考资源

1. [API连线测试]使用Postman测试LINE Notify的讯息推送
2. LINE Notify API Document
3. Postman 新手教学
4. HTTP 状态码一览表

我在 Medium 平台 也分享了许多技术文章
❝ 主题涵盖「MIS & DEVOPS、资料库、前端、後端、MICROSFT 365、GOOGLE 云端应用、自我修炼」希望可以帮助遇到相同问题、想自我成长的人。❞

在许多人的帮助下，本系列文章已出版成书，并添加了新的篇章与细节补充：

• 加入更多实务经验，用完整的开发流程让读者了解专案每个阶段要注意的事项
• 将爬虫的步骤与技巧做更详细的说明，让读者可以轻松入门
• 调整专案架构
  • 优化爬虫程序，以更广的视角来撷取网页资讯
  • 增加资料验证、错误通知等功能，让爬虫执行遇到问题时可以第一时间通知使用者
  • 排程部分改用 node-schedule & pm2 的组合，让读者可以轻松管理专案程序并获得更精确的 log 资讯

有兴趣的朋友可以到天珑书局选购，感谢大家的支持。
购书连结：https://www.tenlong.com.tw/products/9789864348008