If the auction has not finished, calls to /winner should return "UNKNOWN".
/status is similar to /winner, but it is allowed to return the auction's highest bidder using only the local information at a single replica. Unlike with /winner, callers of /status are allowed to observe different values from different replicas. For example, consider the table in "Part II: Replicated auction server." Requests 5 and 6 fetch /status from different replicas and observe different values.
The idea is that /status should eventually converge to the same value at all replicas, but we're willing to tolerate observing slightly stale or inconsistent data. Because we can't control the timing of messages in your applications, we won't be able to enforce strict requirements on how fast /status converges. Your /status implementation should be fine as long as it doesn't do something that's obviously wrong, such as claiming that an agent who never bid is the running winner.
The assignment wasn't explicit on how to handle /status requests for non-existent auctions.
However, it does say this:
For example, if a client on your machine issues an HTTP GET request to http://localhost:8080/winner?name=foo, it should get an HTTP response containing the identifier of the client having the highest bid for auction "foo", if such an auction exists and has ended, or "UNKNOWN" otherwise.
This implies that invalid /winner requests should return "UNKNOWN". For both /winner and /status, I would return "UNKNOWN" for invalid requests.
- Josh