將網頁重新包裝成 Web API

由於 Web API 的逐漸盛行，我們會遇到幾種情境：

• 自行開發的網站，已可供人瀏覽，後來再被要求提供 Web API
• 新功能需同時提供網站與 Web API 雙介面
• 別人有網站，沒有提供 Web API，但我方需要

就第一、二種而言，較佳的做法可能是先完成 Web API，再讓網頁程式呼叫，會是最能減少重工的。但第三種呢？本文就來嘗試探討一番。

以某個實際案例，分析的結果如本文封面圖，可以看出以 User 為中心，向右（外）Request 別人的網站，雖然在第一頁有 CAPTCHA 防機器人，但 Robots.txt 又沒有禁止網頁爬蟲？那我們就能放心地爬，直到最後的第三頁得到真正需要的內容；向左（內）有幾種跨平台工具，分別可以幫我們處理幾種內容的問題。接著就由上而下，分別就每一組來回摘要說明：

1. User GET Page1 這通常是蠻單純的，特別提到 User-Agent 是因為像 Curl Postman 這些非典型瀏覽器，對方會不想理你，所以我們只好向對方宣稱...。回應的部份除了 Body 交後續處理外，還有很重要的便是 Header Cookie 要留下來，下次送回去。
2. 網頁回應不正規的情況時有所聞，主流瀏覽器發展了那麼久，都一直默默忍受著工程師們的不專業，常見的問題可概分為兩大類，一是不符 XML，另一是不符 XHTML。幸好不論是哪一種，我們都可以請 前文 提過的 Tidy 處理．
3. 第一頁對我們有價值的內容，僅僅是防止 Cross-site Request Forgery 的隱藏欄位，但對方一口氣是回了幾萬字，所以我們可以借重一樣在前文提過的 XMLStarlet 用 XPath 把內容萃取出來。
4. CAPTCHA 圖是第一頁上的一個連結，取得時需要搭配 User-Agent、Referer 以及 Cookie，這些都是在 Header 要送過去的，否則對方會不想理你。
5. 如何用工具判讀 CAPTCHA，在 另一篇前文 已有介紹。
6. 要求第二頁，對方需要我們提供客戶代碼與 CAPTCHA 的解讀結果。比較特別的是，這裡還沒有直接答案，回應的頁面上還有一個連結，到第三頁才是終點。
7. 除了重複要求的客戶代碼，第三頁額外再要求一個帳單名稱，這些一起送出才初步得到最後答案。
8. 同 2.
9. 類似 3. 萃取內容

經由以上的步驟，我們可以讓別人的網站成為我們的資料庫，開發 Web API 回應本不屬於我們的內容，如果我們雙方的網站都維護的很好的話。