A campus network team is replacing a legacy NMS integration with a REST service covering 3,000 access switches. Clients must fetch a device by its ID, change only the description field, and keep working after a load-balancer failover with no sticky session. Which REST design for resources, methods and state handling best fits these requirements?
Select an answer to reveal the explanation.
Short Explanation
You’re choosing statelessness: each request carries what the service needs, so any node can handle it after failover. Keeping a login session on the server relies on stored context, while changing a description through GET or posting every update to the collection misuses HTTP method semantics or the resource target.
Full Explanation
Statelessness means the server keeps no client memory between requests, so each call carries its URI, method, credentials and any needed payload. This lets a replacement load-balancer node handle a request after failover without sticky sessions: it has the information needed to respond. For a one-field change, PATCH to the specific device URI targets only the description rather than replacing the full device record. Keeping each login session on the server fails the failover requirement because the new node may not have the stored session context. Sending a description change in a GET body is unsuitable because GET is defined as a safe method for reading, not modifying resource state. Posting every field update to the devices collection uses the collection as the target rather than the individual device, and is not the appropriate method for a partial update; PATCH to that device’s URI is the fit. Exam caveat: statelessness does not prohibit tokens or cookies; it means the server does not rely on stored client context to identify or process a request. Practical check: replay the same authenticated PATCH from two different source addresses and confirm both responses match.