Thanawat Wongchai

Posted on May 8 • Originally published at apidog.com

การใช้งานคอมพิวเตอร์ vs APIs แบบโครงสร้าง: อะไรดีกว่ากัน? (2026)

การขับเคลื่อนเบราว์เซอร์ด้วย LLM ผ่าน “การใช้งานคอมพิวเตอร์” มีต้นทุนสูงกว่าการเรียกใช้ API แบบมีโครงสร้างกับผู้ให้บริการเดียวกันได้ประมาณ 45 เท่า สาเหตุหลักคือทุกขั้นตอนต้องส่งภาพหน้าจอกลับเข้าโมเดลซ้ำ ๆ

ลองใช้ Apidog วันนี้

บทความนี้อธิบายที่มาของตัวเลข 45 เท่า, วิธีตัดสินใจว่าเมื่อใดควรใช้การใช้งานคอมพิวเตอร์, และวิธีออกแบบเส้นทาง API แบบมีโครงสร้างด้วย Apidog ให้เอเจนต์ทำงานเร็วขึ้น ถูกลง และทดสอบได้ง่ายขึ้น แนวคิดนี้ใช้ได้กับ OpenAI Operator, การใช้งานคอมพิวเตอร์ของ Anthropic, browser-use, Skyvern และเครื่องมืออื่นที่ทำงานด้วยลูปภาพหน้าจอ

หากคุณเขียน API สำหรับเอเจนต์ AI ควรอ่านคู่มือเรื่อง วิธีการเขียนไฟล์ agents.md ด้วย เพราะข้อกำหนดแบบนั้นช่วยให้ API แบบมีโครงสร้างกลายเป็นเส้นทางเริ่มต้นที่ชัดเจนสำหรับผู้เรียกใช้

สรุปสั้น ๆ

การใช้งานคอมพิวเตอร์: LLM ดูภาพหน้าจอ แล้วส่งคำสั่งคลิก, พิมพ์, เลื่อน
API แบบมีโครงสร้าง: LLM ส่ง JSON tool call ให้แบ็กเอนด์ดำเนินการ
สำหรับงานเดียวกัน การใช้งานคอมพิวเตอร์มักใช้โทเค็นมากกว่า 30–50 เท่า
ใช้การใช้งานคอมพิวเตอร์เมื่อไม่มี API, API ถูกจำกัด, หรือ workflow อยู่หลัง UI ที่เขียนสคริปต์ได้ยาก
ใช้ API แบบมีโครงสร้างกับงานที่มี endpoint ชัดเจน เช่น payment, search, CRM update, internal tools
แนวทางที่ใช้ได้จริงคือ hybrid: 90% ผ่าน API, 10% ผ่าน browser fallback
ใช้ Apidog เพื่อออกแบบ JSON Schema, mock endpoint, replay request/response และลดการเสียเครดิตเอเจนต์ระหว่างพัฒนา

ทำไมต้นทุนถึงต่างกันมาก

ตัวเลข 45 เท่าไม่ได้เกิดจาก benchmark พิเศษ แต่เกิดจากรูปแบบการใช้โทเค็น

เส้นทาง API แบบมีโครงสร้าง

หนึ่ง request มักประกอบด้วย:

prompt ของผู้ใช้
JSON Schema หรือ tool definition
tool call ที่โมเดลส่งกลับ
HTTP request จาก runtime ไปยัง API จริง

โดยทั่วไปคือโทเค็นขาเข้าไม่กี่ร้อย, โทเค็นขาออกไม่กี่สิบ และ network call หนึ่งครั้ง

เส้นทางการใช้งานคอมพิวเตอร์

หนึ่ง workflow ต้องทำซ้ำเป็นรอบ:

ส่ง prompt พร้อมภาพหน้าจอ
โมเดลตอบพิกัดหรือ action
runtime คลิก/พิมพ์/เลื่อน
จับภาพหน้าจอใหม่
ส่งกลับเข้าโมเดลอีกครั้ง
ทำซ้ำจนจบงาน

งานอย่าง “จองเที่ยวบิน” หรือ “ดึงรายงานจาก dashboard” อาจใช้ 12–30 รอบ แต่ละภาพหน้าจอมีต้นทุนประมาณ 1,500 โทเค็นที่ความละเอียดทั่วไป เมื่อรวม retry, cookie banner, scroll ผิดตำแหน่ง และ action ที่ล้มเหลว ต้นทุนจึงเพิ่มเร็วมาก

เอกสาร การใช้งานคอมพิวเตอร์ ของ Anthropic ระบุการคิดโทเค็นของภาพหน้าจอไว้อย่างเปิดเผย และกระทู้ HN เรื่อง การใช้งานคอมพิวเตอร์แพงกว่า API แบบมีโครงสร้าง 45 เท่า ก็สรุปช่วง 30–50 เท่าซึ่งสอดคล้องกับการรัน workflow เดียวกันผ่านทั้งสองเส้นทางใน Apidog

เมื่อใดควรใช้ API แบบมีโครงสร้าง

ให้ตั้งค่าเริ่มต้นเป็น API แบบมีโครงสร้างเมื่อมีเงื่อนไขเหล่านี้

1. มี OpenAPI, GraphQL schema หรือ REST docs

ถ้ามีรูปแบบ request/response ชัดเจน LLM สามารถเติม argument ให้ tool call ได้ เช่น:

{
  "customer_id": "cus_123",
  "status": "active",
  "limit": 100
}

ความล้มเหลวของ tool call แบบมี schema มักตรวจจับได้ง่าย เช่น required field หาย, enum ไม่ถูกต้อง, date format ผิด และสามารถ retry ได้อย่างเป็นระบบ

2. งานจบด้วย endpoint หนึ่งหรือสองตัว

ตัวอย่างงานที่ไม่ควรเปิด browser:

สร้าง customer ใน Stripe
อัปเดต deal stage ใน HubSpot
โพสต์ข้อความใน Slack
rerun CI job
ค้นหา invoice
ปิด ticket support

ถ้างานจบด้วย HTTP request ได้ การให้เอเจนต์คลิก UI คือ overhead ที่ไม่จำเป็น

3. Workflow ต้องทำงานอัตโนมัติ

Cron job, webhook, queue worker และ background job ไม่ควรพึ่งลูปภาพหน้าจอที่อาจ scroll ผิด, รอโหลดผิดจังหวะ หรือคลิก element ผิดตำแหน่ง

API call มี deterministic boundary ชัดเจนกว่า:

input JSON -> HTTP request -> response JSON -> retry/log/alert

4. Latency สำคัญ

API call มักจบใน 200–800 ms

ลูปการใช้งานคอมพิวเตอร์ 15 รอบอาจใช้ 30–90 วินาที และนานกว่านั้นเมื่อมี retry ถ้าผู้ใช้กำลังรอคำตอบอยู่ ให้เลือก API ก่อนเสมอ

5. ต้อง mock และ test ก่อน deploy

ใน Apidog คุณสามารถ mock JSON endpoint ได้ทันที แล้วให้เอเจนต์เรียก mock server แทน production ได้ การ mock browser screenshot loop ทำได้ยากกว่ามาก

เมื่อใดการใช้งานคอมพิวเตอร์ยังมีประโยชน์

การใช้งานคอมพิวเตอร์ยังเหมาะในบางกรณี

1. พอร์ทัลเก่าที่ไม่มี API

เช่น procurement portal, logistics portal, benefits portal หรือระบบที่อยู่หลัง session ของ ASP.NET และไม่มี machine interface

ในกรณีนี้ การใช้งานคอมพิวเตอร์อาจแทนสคริปต์ Selenium ที่เปราะบางได้ แม้จะแพงกว่า แต่ลดภาระ maintenance ได้

2. เครื่องมือภายในที่แก้ไขไม่ได้

เช่น CRM เก่า, ERP เก่า, SharePoint dashboard หรือ internal admin ที่ไม่มีทีมดูแล integration แล้ว

ถ้าคุณไม่สามารถเพิ่ม API ได้ และปริมาณงานไม่สูง browser agent อาจเป็นทางเลือกที่ใช้ได้

3. งานครั้งเดียวหรือปริมาณต่ำมาก

ตัวอย่าง:

“ช่วยดู competitor 50 ราย แล้วกรอกข้อมูลสำคัญลง Notion”

ถ้างานนี้รันครั้งเดียว การออกแบบ API อาจไม่คุ้ม การใช้งานคอมพิวเตอร์จบงานได้เร็วกว่าในเชิงเวลา implementation

4. งาน scraping ที่ขัดกับข้อกำหนด

ควรหลีกเลี่ยง คำขอประเภท “ใช้ computer use เพื่อ scrape เว็บไซต์นี้” มักเสี่ยงต่อการละเมิดข้อกำหนดของผู้ให้บริการ และต้นทุนไม่ใช่ปัญหาใหญ่ที่สุด

กรอบตัดสินใจแบบเร็ว

ใช้ checklist นี้ก่อนเลือกการใช้งานคอมพิวเตอร์

ตรวจสอบ	ถ้าใช่	ถ้าไม่
มี API ที่มีเอกสารหรือไม่	ใช้ API	ตรวจสอบข้อต่อไป
สร้าง server-side adapter บาง ๆ ครอบ private endpoint ได้หรือไม่	สร้าง adapter แล้ว expose เป็น JSON	ตรวจสอบข้อต่อไป
เป็นงานครั้งเดียวหรือปริมาณต่ำมาก เช่น น้อยกว่า 100 ครั้ง/วัน หรือไม่	ใช้การใช้งานคอมพิวเตอร์ได้	ตรวจสอบข้อต่อไป
ยอมจ่ายโทเค็นเพิ่ม 30–50 เท่าต่อรันได้หรือไม่	ใช้การใช้งานคอมพิวเตอร์	หยุด แล้วเจรจาหรือสร้าง API

โดยทั่วไป workflow ส่วนใหญ่จะจบตั้งแต่ข้อ 1 หรือข้อ 2 การใช้งานคอมพิวเตอร์ควรเหลือไว้เฉพาะกรณีที่ไม่มี API และสร้าง adapter ไม่ได้จริง ๆ

ตัวอย่าง API แบบมีโครงสร้างในเอเจนต์

สมมติผู้ใช้ถาม:

“Show yesterday's failed payments.”

แนวทางที่ต้องการคือให้โมเดลเรียก tool แทนการเปิด Stripe dashboard

import json
from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "list_failed_payments",
            "description": "List failed payments in a date range",
            "parameters": {
                "type": "object",
                "properties": {
                    "start": {
                        "type": "string",
                        "format": "date"
                    },
                    "end": {
                        "type": "string",
                        "format": "date"
                    }
                },
                "required": ["start", "end"]
            }
        }
    }
]

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {
            "role": "user",
            "content": "Show yesterday's failed payments."
        }
    ],
    tools=tools,
    tool_choice="auto"
)

call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)

payments = stripe.PaymentIntent.list(
    created={
        "gte": args["start"],
        "lte": args["end"]
    },
    limit=100
)

ลำดับงานมีแค่:

user prompt -> tool call JSON -> Stripe API -> response

เอเจนต์ไม่ต้องเห็น dashboard, ไม่ต้องคลิก date picker, ไม่ต้องอ่านตัวเลขจากพิกเซล และไม่ต้องจ่ายโทเค็นภาพหน้าจอซ้ำ ๆ

ถ้าทำด้วยการใช้งานคอมพิวเตอร์ workflow เดียวกันอาจกลายเป็น:

open browser
login
screenshot
click date filter
screenshot
select range
screenshot
filter failed
screenshot
scroll table
screenshot
extract result

สิบกว่ารอบเป็นเรื่องปกติ และแต่ละรอบมีต้นทุนภาพหน้าจอ

ออกแบบเส้นทางแบบมีโครงสร้างด้วย Apidog

ปัญหาที่ทำให้ทีมเลือก browser agent มักไม่ใช่เพราะจำเป็นจริง ๆ แต่เพราะไม่มีใครออกแบบ tool surface ให้เอเจนต์เรียกใช้อย่างเป็นระบบ

ใช้ Apidog เพื่อทำ workflow นี้

ขั้นตอนที่ 1: นิยาม operation ที่เอเจนต์ต้องใช้

เริ่มจาก operation ที่เกิดซ้ำ เช่น:

list_invoices
create_customer
update_deal_stage
send_slack_message
rerun_ci_job
list_failed_payments

ออกแบบเป็น endpoint ใน Apidog พร้อม request/response schema

ตัวอย่าง endpoint:

POST /tools/list-failed-payments
Content-Type: application/json

request body:

{
  "start": "2026-01-01",
  "end": "2026-01-02"
}

response body:

{
  "payments": [
    {
      "id": "pi_123",
      "amount": 9900,
      "currency": "usd",
      "failed_reason": "card_declined"
    }
  ]
}

ขั้นตอนที่ 2: ส่งออก OpenAPI 3.1

Apidog สร้าง OpenAPI 3.1 จาก design view ได้ จากนั้นนำ schema ไปใช้กับ:

OpenAI tools
Anthropic tool use schema
LangChain OpenAPI loader
runtime ของเอเจนต์ที่รองรับ JSON Schema

ขั้นตอนที่ 3: เปิด mock server

เปิด mock server ใน Apidog เพื่อให้เอเจนต์เรียก endpoint จำลองก่อนต่อ production

ข้อดี:

ทดสอบ prompt และ tool routing ได้ทันที
ไม่กระทบข้อมูลจริง
ไม่เสียค่าใช้จ่ายจาก API จริง
ลดรอบ debug ระหว่างออกแบบ

ดูแนวคิดแบบ contract-first เพิ่มได้ที่ คู่มือการพัฒนาแบบสัญญามาก่อนของ Apidog

ขั้นตอนที่ 4: Replay request/response

เมื่อเอเจนต์รัน ให้บันทึก request และ response ทุกครั้ง

สิ่งที่ควรตรวจสอบ:

tool ไหนถูกเรียก
argument ที่โมเดลสร้างถูก schema หรือไม่
endpoint ตอบ error อะไร
retry เกิดเพราะ model, runtime หรือ API
run ที่ผ่านกับ run ที่ล้มเหลวต่างกันตรงไหน

นี่คือวิธีลดปัญหา “เมื่อวานเอเจนต์ทำงานได้ วันนี้พัง”

ขั้นตอนที่ 5: ใช้โปรเจกต์เดียวกันเป็นเอกสารและชุดทดสอบ

โปรเจกต์ใน Apidog สามารถใช้เป็น:

API documentation
mock server
test cases
QA workflow
monitoring/debug reference
contract สำหรับทีม backend และทีม AI

สถาปัตยกรรมแบบ Hybrid

ในระบบจริง เอเจนต์จำนวนมากจะใช้ทั้งสองเส้นทาง:

90% ผ่าน tool/API แบบมีโครงสร้าง
10% fallback ไป browser agent สำหรับระบบเก่าที่ไม่มี API
router เป็นตัวตัดสินใจว่าจะใช้เส้นทางใด

ตัวอย่างแนวคิด router:

known_tools = {
    "list_failed_payments",
    "create_customer",
    "update_deal_stage",
    "send_slack_message"
}

def route_action(action_name: str):
    if action_name in known_tools:
        return "structured_tool"
    return "browser_agent"

system prompt แบบสั้น:

ถ้า operation มีอยู่ใน known_tools ให้เรียก structured tool
ถ้าไม่มี ให้ส่งต่อไปยัง browser agent
อย่าใช้ browser ถ้ามี structured tool ที่ทำงานเดียวกันได้

Anthropic Claude 4.5, OpenAI GPT-5.5 และ DeepSeek V4 สามารถใช้ routing pattern ลักษณะนี้ได้ ดูรูปแบบ request ของ DeepSeek ได้ที่ วิธีใช้ DeepSeek V4 API

Metric ที่ควรแยกติดตาม

แยก observability ของสองเส้นทางนี้ออกจากกัน:

Metric	Structured API	Computer use
จำนวน run	ควรสูง	ควรต่ำ
latency	ต่ำ	สูง
token cost/run	ต่ำ	สูง
failure mode	schema/API error	UI drift, click error, screenshot retry
retry strategy	deterministic	non-deterministic

สัญญาณอันตรายคือ browser fallback เริ่มกิน volume หรือ cost มากขึ้นเรื่อย ๆ ถ้าเกิดขึ้น ให้กลับไปออกแบบ endpoint เพิ่ม

ข้อผิดพลาดที่ควรหลีกเลี่ยง

1. ไม่มี JSON Schema

อย่าส่งแค่ prompt แล้วหวังว่าโมเดลจะสร้าง JSON ถูกเสมอ

ควรใช้ schema ที่เข้มงวด:

{
  "type": "object",
  "properties": {
    "customer_id": {
      "type": "string"
    },
    "status": {
      "type": "string",
      "enum": ["active", "inactive", "blocked"]
    }
  },
  "required": ["customer_id", "status"]
}

2. ให้เอเจนต์ออกแบบ schema ตอน runtime

Schema คือ product surface ควรออกแบบ, version, review และ test เหมือน public API

อย่าปล่อยให้เอเจนต์เปลี่ยน contract เองระหว่าง runtime เพราะจะทำให้ production behavior คาดเดายาก

3. ดูเฉพาะจำนวนโทเค็น แต่ไม่ดูค่าใช้จ่ายจริง

โทเค็นภาพอาจถูกคิดราคาแตกต่างจาก text token ตรวจสอบ billing console ของ provider ไม่ใช่ดูแค่ dashboard tracing ภายใน

4. สับสนระหว่าง computer use กับ RPA

RPA: คลิกตาม script บน DOM หรือ selector ที่รู้จัก
Computer use: โมเดลตัดสินใจจากภาพหน้าจอทุกครั้ง

ถ้า UI คงที่และ selector ใช้ได้ Playwright หรือ Puppeteer อาจถูกกว่าและควบคุมง่ายกว่า

5. ลืมต้นทุนด้าน latency

ต้นทุน 45 เท่าไม่ใช่แค่ค่าโทเค็น แต่รวมถึงเวลารอของผู้ใช้ด้วย ถ้า workflow อยู่ใน user-facing path ให้ใช้ API เป็นค่าเริ่มต้น

ทางเลือกก่อนใช้การใช้งานคอมพิวเตอร์

ถ้าผู้ขายไม่มี public API แต่มี UI ที่เข้าใจได้ ลองพิจารณาทางเลือกเหล่านี้ก่อน

1. Headless browser script

ใช้ Playwright หรือ Puppeteer เมื่อ:

UI ค่อนข้างนิ่ง
selector เสถียร
workflow ต้องรันซ้ำจำนวนมาก
ทีมรับ maintenance ได้

หลังพัฒนาแล้วไม่มีค่าโมเดลต่อรัน แต่ต้องรับความเสี่ยงเมื่อ UI เปลี่ยน

2. Zapier หรือ Make connector

ถ้าผู้ขายมี connector อยู่แล้ว iPaaS อาจถูกกว่าการสร้าง integration เองหรือใช้ browser agent ระยะยาว

3. Private API ที่ reverse engineer ได้

เปิด DevTools แล้วดู Network tab หลาย dashboard เรียก JSON endpoint ภายในอยู่แล้ว

แนวทาง:

ตรวจสอบ request ที่ UI ส่ง
ระบุ endpoint, method, header, body
สร้างเอกสารใน Apidog
ใช้เป็น internal adapter
ถือว่า stability อยู่ระดับปานกลาง เพราะ vendor อาจเปลี่ยนได้

แนวทางคล้ายกันถูกกล่าวถึงใน การทดสอบ API โดยไม่ต้องใช้ Postman

สรุปคือ การใช้งานคอมพิวเตอร์ควรเป็นทางเลือกสุดท้าย ไม่ใช่ค่าเริ่มต้น

กรณีการใช้งานจริง

ทีม compliance ของ fintech แทนที่รายงาน Stripe ที่ใช้ computer use 6 ขั้นตอนด้วย structured call 3 ครั้ง ผลคือค่าโทเค็นลดลง 92% และ runtime ลดจาก 41 วินาทีเหลือ 2 วินาที

เอเจนต์ support ของ B2B SaaS ใช้ computer use เฉพาะ workflow เดียวคือ procurement portal ที่ไม่มี API ส่วน workflow อื่น route ผ่าน OpenAPI tool ที่ออกแบบใน Apidog ค่าโทเค็นรวมลดจาก 4,200 ดอลลาร์เหลือ 310 ดอลลาร์ต่อเดือน

ผู้ก่อตั้งคนเดียวใช้ computer use สัปดาห์ละครั้งเพื่อ refresh Notion dashboard จาก ERP เก่า แม้ต้นทุนต่อรันแพงกว่า แต่เมื่อรันน้อยมาก ค่าใช้จ่ายจริงเป็นเพียงไม่กี่เซ็นต์ และถูกกว่าการทำ integration หลายสัปดาห์

บทสรุป

ตัวเลข 45 เท่าเป็นสัญญาณสำคัญสำหรับทีมที่กำลังสร้าง AI agent ให้ตั้งค่าเริ่มต้นเป็น API แบบมีโครงสร้างที่ออกแบบใน Apidog และใช้การใช้งานคอมพิวเตอร์เฉพาะเมื่อไม่มี API หรือ workflow มีปริมาณต่ำพอที่ต้นทุนไม่สำคัญ

สิ่งที่ควรทำทันที:

ลิสต์ action ทั้งหมดที่เอเจนต์ต้องทำ
แยก action ที่มี API หรือสร้าง adapter ได้
ออกแบบ endpoint และ JSON Schema ใน Apidog
เปิด mock server แล้วให้เอเจนต์ทดสอบกับ mock ก่อน
วัด cost, latency, retry และ fallback rate แยกกัน
ใช้ browser agent เฉพาะส่วนที่ไม่มีทางเลือกจริง ๆ

ขั้นตอนต่อไป: เปิด Apidog, สร้างโปรเจกต์สำหรับ tool surface ของเอเจนต์, เปิด mock server และตรวจสอบว่า workflow ที่ตั้งใจจะทำด้วย computer use สามารถยุบเป็น structured call หนึ่งหรือสองครั้งได้หรือไม่

คำถามที่พบบ่อย

การใช้งานคอมพิวเตอร์ถูกกว่า API แบบมีโครงสร้างหรือไม่?

ไม่ใช่ต่อการรัน โทเค็นจากภาพหน้าจอทำให้ต้นทุนสูงกว่า แต่ computer use อาจถูกกว่าในภาพรวมถ้า workflow มีปริมาณต่ำมาก และต้นทุนการสร้าง integration สูงกว่าค่า run หลายปี

ฉันจะ mock JSON tool surface สำหรับเอเจนต์ได้อย่างไร?

ออกแบบ endpoint ใน Apidog, เปิด mock server ในตัว แล้วชี้เอเจนต์ไปที่ mock URL ทุก request จะได้ JSON response ที่สมจริงโดยไม่ต้องแตะ production ดู workflow เพิ่มได้ที่ เครื่องมือทดสอบ API สำหรับวิศวกร QA

ใช้ OpenAPI สำหรับ tool calling ได้กับทุกโมเดลหรือไม่?

ได้กับโมเดลและ runtime ที่รองรับ tool calling เช่น OpenAI tools, Anthropic tool_use และ DeepSeek V4 Apidog ส่งออก schema ได้สะอาด ดูตัวอย่าง request ของ DeepSeek ได้ที่ วิธีใช้ DeepSeek V4 API

GPT-5.5 ยังรองรับการใช้งานคอมพิวเตอร์หรือไม่?

OpenAI ส่งมอบความสามารถด้าน computer use ผ่าน Operator และ Responses API โปรไฟล์ต้นทุนยังคล้ายกับแนวทางที่ใช้ภาพหน้าจอต่อภาพหน้าจอ คำแนะนำในบทความนี้ใช้ได้โดยไม่ผูกกับผู้ให้บริการรายใดรายหนึ่ง

แล้ว Skyvern, browser-use และเอเจนต์โอเพนซอร์สอื่น ๆ ล่ะ?

หลักการคำนวณเหมือนกัน เครื่องมือเหล่านี้อาจลดต้นทุนต่อรันด้วยโมเดลโอเพนซอร์สที่ถูกกว่า แต่จำนวนรอบและขนาดภาพหน้าจอยังใกล้เคียงกัน ถ้ามี API แบบมีโครงสร้าง API จะยังชนะด้านต้นทุน, latency และ reliability

จะรู้ได้อย่างไรว่าขาด endpoint ใดสำหรับงานเอเจนต์?

ดูว่าเอเจนต์ fallback ไป browser agent ตอนไหน ถ้า action เดิมเกิด fallback ซ้ำ แปลว่า tool surface ยังขาด endpoint นั้น ให้เพิ่ม endpoint ใน Apidog, สร้าง schema ใหม่, mock/test แล้ว route action นั้นกลับมาใช้ structured API แทน browser fallback