技能 api-patterns
📦

api-patterns

安全

使用模式指導設計更好的 API

沒有明確設計原則的 API 會導致介面不一致和開發者體驗不佳。此技能提供決策樹和最佳實踐，幫助您選擇正確的 API 樣式並正確實作它。

支援: Claude Codex Code(CC)
🥉 75 青銅
1

下載技能 ZIP

2

在 Claude 中上傳

前往 設定 → 功能 → 技能 → 上傳技能

3

開啟並開始使用

測試它

正在使用「api-patterns」。 Should I use REST or GraphQL for a mobile app with complex data relationships?

預期結果:

GraphQL 更適合您的使用情況，原因如下：1）行動應用程式受益於靈活的查詢以減少過度擷取，2）多個前端平台可以精確請求所需內容，3）複雜的資料圖自然映射到 GraphQL 結構描述。然而，如果您的團隊熟悉它且您有查詢成本分析的基础設施，請考慮使用 GraphQL。

正在使用「api-patterns」。 What HTTP status codes should I use for a POST endpoint that creates a user?

預期結果:

成功建立使用者時使用 201 Created，無效輸入時使用 400 Bad Request，電子郵件已存在時使用 409 Conflict，伺服器錯誤時使用 500。在回應主體中包含建立的使用者，並將 Location 標頭設為新資源 URI。

安全審計

安全
v1 • 2/24/2026

All 67 static findings are false positives. The skill is a documentation resource for API design patterns. Backticks detected are markdown code formatting, not shell commands. No weak cryptography or reconnaissance tools present.

12
已掃描檔案
735
分析行數
2
發現項
1
審計總數
中風險問題 (1)
api-style.md:7-24graphql.md:7-41trpc.md:7-41rest.md:7-14
Markdown Code Blocks Flagged as Shell Commands
Static analyzer detected backticks in markdown files and flagged them as 'Ruby/shell backtick execution'. These are documentation code blocks for API decision trees and examples, not actual shell commands.
低風險問題 (1)
rest.md:34-38security-testing.md:59security-testing.md:102
HTTP Status Code Terms Flagged as Reconnaissance
Security testing documentation mentions standard HTTP status codes (401 Unauthorized, 403 Forbidden) and SSRF testing concepts. These are legitimate API security education topics, not reconnaissance tools.
審計者: claude

品質評分

45
架構
100
可維護性
87
內容
50
社群
98
安全
91
規範符合性

你能建構什麼

選擇 API 架構

開發者正在啟動新專案，需要根據其前端堆疊和資料複雜度在 REST、GraphQL 或 tRPC 之間做出決定。

設計 REST 端點

團隊正在實作 REST API，需要有關資源命名、HTTP 方法和正確狀態碼使用的指導。

API 安全審查

安全工程師使用 OWASP API Top 10 清單對現有 API 進行常見漏洞審計。

試試這些提示

API 樣式選擇 
I am building a [describe your project, e.g., e-commerce app with React frontend and Node.js backend]. What API style should I use? What are the trade-offs?
REST 端點設計 
I need to design REST endpoints for [describe resource, e.g., user management with profiles, posts, and comments]. Show me the proper URL structure, HTTP methods, and status codes.
API 錯誤處理 
What is the best way to handle errors in my API? Show me the proper response format and which HTTP status codes to use for [list error scenarios].
API 版本控制策略 
How should I version my API? I expect the API to evolve over time. Compare URI versioning, header versioning, and query parameter versioning.

最佳實務

  • 根據客戶端需求而非個人偏好選擇 API 樣式 - 考慮前端堆疊、資料複雜度和快取需求
  • 在所有端點中使用一致的信封回應和標準錯誤格式
  • 從一開始就實作速率限制，並在 API 文件中清楚說明限制

避免

  • 在 REST 端點中使用動詞（例如 /getUsers 而非 GET /users）
  • 對不同端點中的相同資源回應不同的格式
  • 向 API 客戶端暴露內部錯誤訊息和堆疊追蹤

常見問題

什麼時候應該選擇 REST 而不是 GraphQL？
為需要廣泛相容性、簡單 CRUD 操作或 HTTP 快取重要的公共 API 選擇 REST。為複雜資料關係、多個前端平台或客戶端需要靈活查詢時選擇 GraphQL。
最好的 API 版本控制策略是什麼？
URI 版本控制（例如 /v1/users）最常見且可見性最高。標頭版本控制更整潔但較難發現。查詢版本控制（例如 /users?version=1）適用於小幅變更，但可能使 URL 雜亂。
如何在 API 中處理分頁？
對大型資料集和無限滾動使用基於游標的分頁。對已知頁面大小使用基於偏移量的分頁。在有用時包含總數，並在回應中提供上一頁/下一頁連結。
401 和 403 狀態碼有什麼區別？
401 Unauthorized 表示驗證缺失或無效。403 Forbidden 表示驗證有效但使用者缺乏存取請求資源的權限。
我應該使用 JWT 還是基於會話的驗證？
JWT 更適合無狀態 API 和微服務。會話驗證適合傳統的伺服器渲染應用程式。考慮您的擴展需求和客戶端類型。
如何保護我的 API 免受常見攻擊？
實作速率限制、驗證所有輸入、使用參數化查詢、實作正確的授權檢查（BOLA）、在生產環境停用內省，並遵循 OWASP API Top 10 指南。

開發者詳情

作者

sickn33

授權

MIT

儲存庫

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/api-patterns

引用

main

檔案結構

📁 scripts/

📄 api_validator.py

📄 api-style.md

📄 auth.md

📄 documentation.md

📄 graphql.md

📄 rate-limiting.md

📄 response.md

📄 rest.md

📄 security-testing.md

📄 SKILL.md

📄 trpc.md

📄 versioning.md