Python 建立網站使用心得站

很多人做到 Flask 網站的某個階段後，會開始碰到一個問題：如果前端不只是模板，而是要用 JavaScript、Vue、React 或其他工具來取資料，那 Flask 要怎麼配合？這時候就會進入 API 的概念。

先講最簡單的理解。API 其實就是讓前端或其他程式透過網址向後端拿資料、送資料，而後端回的不是 HTML，而是 JSON 這類結構化資料。也就是說，傳統 Flask 頁面路由通常是回 `render_template()`，而 API 路由則比較常回 `jsonify()`。

例如最基本的 API 可以長這樣：

from flask import jsonify

@app.route('/api/posts')
def api_posts():
    return jsonify([
        {'title': '第一篇'},
        {'title': '第二篇'},
    ])

這和一般文章頁最大的差別就是，使用者打開文章頁時看到的是 HTML；而前端程式打開 API 時拿到的是 JSON，接著再自己決定怎麼顯示。

如果你把 API 的用途放在內容站裡看，最常見的場景通常有三種。第一，是前端要做搜尋、篩選、分頁這種比較動態的互動。第二，是登入後台可能要用 JavaScript 做更流暢的操作。第三，是未來如果你想讓 Vue 或 React 介面接進來，就幾乎一定會用到 API。

再往下一步，就會碰到 CRUD 這個概念。CRUD 代表 Create、Read、Update、Delete，也就是新增、讀取、更新、刪除。以文章站來說，大概可以這樣理解：

Create：新增文章
Read：讀取文章列表與單篇文章
Update：修改文章
Delete：刪除文章

如果你要做最基本的文章 API，思路通常就是把這四件事各自對應成不同路由。像是 `/api/posts` 取列表、`/api/posts/1` 取單篇、`POST /api/posts` 新增、`PUT /api/posts/1` 更新、`DELETE /api/posts/1` 刪除。

當然，這不代表你一開始就一定要把整站做成 API first。對很多 Flask 小站來說，更合理的順序通常是：先把模板站做穩，再挑真正需要互動的地方加 API。因為如果你連文章頁、表單、資料庫流程都還沒弄順，就一開始整站 API 化，通常只會讓理解成本變高。

所以比較務實的思路是：API 不是和 Flask 網站對立的東西，而是 Flask 在不同需求下的另一種輸出方式。你可以同時有頁面路由和 API 路由，公開文章頁給讀者看，另外提供 JSON 給前端互動或後台操作。當你這樣理解後，Flask 的彈性其實會變得很大。