風変わりなウェブサービスの世界で、No-as-a-Service（NAAS）と呼ばれる新しい API が開発者やテック愛好家の注目を集めています。シンプルな API エンドポイントを通じてランダムな拒否レスポンスを提供するこの軽量サービスは、開発者コミュニティ内で面白さと技術的批評の両方を引き起こしています。
レート制限の問題
このサービスは当初、IP アドレスごとに1分間に10リクエストという厳格なレート制限を実装していましたが、これはすぐにユーザーにとって問題点となりました。多くのコメント投稿者は、10件のリクエストに全く近づいていないにもかかわらず、「Too many requests, please try again later」（リクエストが多すぎます。後でもう一度お試しください）というエラーメッセージを受け取ったと報告しています。これは、レート制限の適用方法に根本的な実装上の問題があることを示唆していました。
あるユーザーは、レート制限が個々のユーザーの IP ではなく、 Cloudflare の 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ごとに1分あたり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 ステータスコード、TLS の問題、無効な構文レスポンスなど、HTTP クライアントのテストに役立つ可能性のある様々な失敗モードを含めるようサービスを拡張することを提案しました。
技術的な制限にもかかわらず、多くのユーザーがプロジェクトのユーモアとシンプルさを評価しました。このサービスは、最も基本的な実装でさえもエンターテイメント価値を提供し、開発者コミュニティで魅力的な技術的議論を引き起こす可能性があることを示しています。目新しさとして見るか、学習の機会として見るかにかかわらず、No-as-a-Service はあらゆる経験レベルの開発者に共感を呼ぶ API 設計への軽快なアプローチを提供しています。
参考: no-as-a-service