RESTful Resource Naming and HTTP Verbs — Node.js & Express Backend

REST is the most widely adopted architectural style for HTTP APIs, yet it is also among the most widely misunderstood. Most developers know that GET retrieves data and POST creates it, but the deeper principles of REST, uniform resource identification, stateless client-server interaction, and the semantic contracts implied by HTTP methods, are routinely violated even in APIs that claim to be RESTful. These violations accumulate as technical debt: an endpoint named /getPlayerStats that accepts POST requests is harder to cache, harder to document, harder to test, and harder for a new developer to understand than a properly designed /api/v1/players/:id/stats endpoint that responds to GET. This lesson establishes the precise rules for resource naming and HTTP verb semantics so that your APIs communicate their intent clearly through their URLs and methods alone, before a client reads a single line of documentation.

Analogy🏏Cricket

🏏 Think of it like cricket: In a Test match, there are multiple types of scheduled breaks and interruptions, each with different priority levels and timing rules. The lunch break (setTimeout) is scheduled for a specific time but can be delayed if a wicket falls just before — it fires at the next available opportunity after its scheduled time, not at the exact scheduled time. The drinks break (setImmediate) is taken at the end of the current over, as soon as the ongoing delivery sequence finishes. The umpire's over-rate check (process.nextTick) happens immediately after each delivery, before the next batsman faces — it cannot be deferred. The DRS review resolution (Promise microtask) happens between deliveries, after the umpire check but before any scheduled breaks. Just as the match referee would be furious if an umpire kept conducting over-rate checks after every single ball indefinitely (starving nextTick), the event loop is unable to proceed if process.nextTick callbacks keep registering new nextTick callbacks recursively. The insight is that each timer primitive is not just a delay mechanism — it is a specific position in a formal protocol, and misusing it violates that protocol's invariants.