A platform team reviews a Python FastAPI service that fronts their network inventory. Clients POST /login first, the server then keeps a session object holding that client's device list, GET /devices returns the cached list, and a delete is triggered with GET /devices?action=delete. Which redesign would make the service follow REST resource naming and statelessness rules?
Select an answer to reveal the explanation.
Short Explanation
REST wants URLs to name things, methods to say what happens, and the server to remember nothing between calls — that's statelessness. Your service breaks two of those rules with a stored session and a query-flag delete. Fix the path, use DELETE, and let every request stand on its own.
Full Explanation
REST models an application as resources addressed by URIs, with the HTTP method supplying the verb, and it requires each request to be self-contained. Addressing one device as /devices/{id} and removing it with DELETE gives the operation its own identity, correct caching and retry behaviour, and an interface clients can predict; requiring credentials and context on every call satisfies statelessness, because the server then holds nothing between requests. Keeping a per-user session object keeps the service stateful even with a short timeout, which forces session affinity on the load balancer and breaks when a worker restarts. The remote procedure call approach inverts the model by naming actions instead of things, so one endpoint does many jobs and clients cannot reason about representations. Treating action=delete as a query flag violates the rule that GET must be safe and idempotent, so a prefetch, crawler, or retried request can delete data. Exam caveat: query strings remain perfectly valid for filtering and paging, they simply must not change state. Practical check: send the device list GET twice with a browser refresh and confirm the device count is unchanged.