In the world of quirky web services, a new API called No-as-a-Service (NAAS) has caught the attention of developers and tech enthusiasts. This lightweight service, which provides random rejection responses through a simple API endpoint, has sparked both amusement and technical critique within the developer community.
Rate Limiting Woes
The service initially implemented a strict rate limit of 10 requests per minute per IP address, which quickly became a pain point for users. Many commenters reported receiving the error message Too many requests, please try again later despite not having made anywhere near 10 requests. This suggested a fundamental implementation issue with how the rate limiting was being applied.
One user identified that the rate limiting was likely being applied to Cloudflare's IP address rather than individual user IPs, causing all users behind the same Cloudflare node to share the same rate limit quota. This observation was supported by the presence of Express headers in the response, indicating that the rate limiting was happening at the application level rather than at the CDN level.
In response to this widespread feedback, the developer (hotheadhacker) eventually removed the rate limiting entirely, announcing simply: The API rate limiting has been removed.
No-as-a-Service API Details:
- Base URL: https://naas.isalman.dev/no
- Method: GET
- Initial Rate Limit: 10 requests per minute per IP (now removed)
- Response Format: JSON with a "reason" field
- GitHub Repository: https://github.com/hotheadhacker/no-as-a-service
Implementation Issues:
- Only 25-26 unique responses despite claiming "1000+"
- Some responses repeated up to 50 times in the reasons.json file
- Rate limiting initially applied at proxy level rather than origin IP
Duplicate Response Issues
Another significant discussion point centered around the quality and uniqueness of the rejection messages. Despite the documentation claiming 1000+ universal rejection reasons, users who examined the source code discovered that the reasons.json file contained mostly duplicates of the same 25 responses.
I made a lot of things like this as a noob and threw them up on github. As you gain experience, these projects become a testament to how far you've come.
Some speculated that the duplication might be an intentional approach to create a weighted distribution system, where certain responses appear more frequently than others. Others suggested it might simply be an artifact of using an LLM to generate the list, as large language models often repeat entries when asked to produce lengthy lists.
Implementation Considerations
The project's simplicity sparked interesting discussions about code organization and collaboration. Some developers suggested that storing responses in a single large JSON file could create merge conflicts when accepting contributions, proposing alternative approaches like using a folder of plain text files grouped by theme or contributor.
Others countered that for such a lightweight service, the current implementation was sufficient, noting that Git merge conflicts in a simple line-by-line file would be relatively easy to resolve.
The community also proposed potential improvements, including more sophisticated error handling that would maintain the humorous tone of the service even when rate limited. One user suggested expanding the service to include various failure modes that could be useful for testing HTTP clients, such as different HTTP status codes, TLS issues, and invalid syntax responses.
Despite its technical limitations, many users appreciated the humor and simplicity of the project. The service demonstrates that even the most basic implementations can provide entertainment value and spark engaging technical discussions in the developer community. Whether viewed as a novelty or a learning opportunity, No-as-a-Service offers a lighthearted approach to API design that resonates with developers at all experience levels.
Reference: no-as-a-service