在各種奇特網路服務的世界中，一個名為 No-as-a-Service (NAAS) 的新 API 引起了開發者和技術愛好者的關注。這個提供隨機拒絕響應的輕量級服務透過簡單的 API 端點，在開發者社群中引發了既有趣味又有技術批評的討論。
速率限制困境
該服務最初實施了嚴格的速率限制，每個 IP 地址每分鐘限制 10 個請求，這很快成為使用者的痛點。許多評論者報告收到錯誤資訊Too many requests, please try again later（請求過多，請稍後再試），儘管他們的請求遠未達到 10 個。這表明速率限制的實施方式存在根本性問題。
一位使用者指出，速率限制可能是應用於 Cloudflare 的 IP 地址而非個別使用者的 IP，導致同一 Cloudflare 節點背後的所有使用者共享相同的速率限制配額。響應中出現 Express 頭資訊支援了這一觀察，表明速率限制是在應用程式級別而非 CDN 級別發生的。
針對這些廣泛的反饋，開發者（hotheadhacker）最終完全移除了速率限制，簡單地宣佈：The API rate limiting has been removed.（API 速率限制已被移除）。
No-as-a-Service API 詳情：
- 基礎 URL：https://naas.isalman.dev/no
- 請求方法：GET
- 初始請求限制：每個 IP 每分鐘 10 個請求（現已移除）
- 響應格式：帶有"reason"欄位的 JSON
- GitHub 倉庫：https://github.com/hotheadhacker/no-as-a-service
實現問題：
- 儘管聲稱有"1000+"，但實際上只有25-26個獨特響應
- 在 reasons.json 檔案中，某些響應重複多達50次
- 速率限制最初在代理級別應用，而非源 IP 級別
重複響應問題
另一個重要的討論點集中在拒絕資訊的質量和獨特性上。儘管文件聲稱有1000+通用拒絕理由，但檢查原始碼的使用者發現，reasons.json 檔案中大多是相同的 25 個響應的重複。
「我作為新手時也做過很多這樣的東西並把它們放到 github 上。隨著經驗的積累，這些專案成為了你進步有多大的見證。」
一些人推測，這種重複可能是有意為之，目的是建立一個加權分佈系統，使某些響應比其他響應出現得更頻繁。其他人則認為這可能只是使用 LLM 生成列表的產物，因為大型語言模型在被要求生成長列表時經常會重複條目。
實現考慮
該專案的簡單性引發了關於程式碼組織和協作的有趣討論。一些開發者建議，將響應儲存在單個大型 JSON 檔案中可能會在接受貢獻時產生合併衝突，他們提出了替代方案，如使用按主題或貢獻者分組的純文字資料夾。
其他人則反駁說，對於這樣一個輕量級服務，當前的實現已經足夠，並指出在簡單的逐行檔案中解決 Git 合併衝突相對容易。
社群還提出了潛在的改進，包括更復雜的錯誤處理，即使在速率受限時也能保持服務的幽默基調。一位使用者建議擴充套件服務，包括各種對測試 HTTP 客戶端有用的故障模式，如不同的 HTTP 狀態碼、TLS 問題和無效語法響應。
儘管存在技術侷限性，許多使用者仍然欣賞該專案的幽默和簡單。該服務表明，即使是最基本的實現也能提供娛樂價值，並在開發者社群中引發有趣的技術討論。無論被視為新奇事物還是學習機會，No-as-a-Service 都提供了一種輕鬆的 API 設計方法，能夠引起各經驗水平開發者的共鳴。