Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Appropriate HTTP status code for "user confirmation required"
I'm working on a system where the frontend will make a call to the backend to perform an action.
Sometimes this action can cause other unintended consequences (like charging the customer), in these circumstances I want the backend to respond with a status code indicating
What you did is fine, just make sure that's what you want to do because it will do XYZ
Essentially if the frontend got this response it just means prompt the user to confirm the changes and submit the request again (perhaps with different attributes based on their selection).
In most cases we don't need a confirmation, that's why I don't want to implement it on all requests. There are specific circumstances that require an extra layer of confirmation (and once confirmed the request can proceed as usual or slightly differently depending on what the user selected).
I'd like to know if there's a specific response code that would be appropriate to give to the frontend to indicate that further action is required.
The best one I could come up with was 202 Accepted, though I'm not sure it's correct based on what I described above.
2 answers
I doubt that there is an actual standard HTTP response code to indicate exactly what you're looking for. 202 (Accepted) is close, but doesn't really seem to me to be about a situation where the client should resubmit the request; by the definition in the RFCs, it's more of a "the request has been added to the work queue" than a "no action has yet been taken, but the request is acceptable for resubmission".
Even the formal definitions of these status codes go back to 1996 (RFC 1945) and don't seem to have changed much since then. The Web was a very different place back then...
Personally, since the server understood and was able to successfully parse and process the request (only that the outcome isn't yet finalized), I would probably opt for the good old 200 (OK) response with a machine-readable response body indicating to the client that further confirmation is required. For cases where no further confirmation is required, the response would be similar but the response body would indicate either proper success or failure. The response body could be JSON, XML, or something else, depending on other requirements.
The contract between the client and the server then becomes something like HTTP 200 for "meaningfully processed request", and the response body indicating further details about the outcome of that processing. That seems to me to be roughly in line with the intent of an "OK" response from the server, even when the request resulted in no actual action being taken.
0 comment threads
Unless there are reasons for keeping the "check for unintended consequences" and "perform the action" in the same endpoint, I would split them into two parts:
-
GET /api/v1/action-can-charge-the-client/{id}. This should respond with 200 and the required information so that the client knows that confirmation is required. -
POST /api/v1/perform-action-that-might-charge-the-client/{id}. This should actually perform the action, including charging the client. If the client waits (synchronously) for the OK, I would return a 200. If the client just starts the action (synchronously), I would return a 202.
This solution splits two rather different concerns (is it going to cost me? vs. do the thing even if it charges me) and also provides a "query"/"command" separation.
I am not sure about the performance and security though. Typically separating "queries" from "commands" helps with scalability and maintenance.
If for whatever reason, the client must explicitly acknowledge that a payment might occur when calling perform-action-that-might-charge-the-client, an "AcceptThatChargeMightHappen" boolean can be included in the payload (default value false).
0 comment threads
0 comment threads