Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Notifications
Mark all as read
Q&A

Appropriate HTTP status code for "user confirmation required"

+4
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

2 answers

+5
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+5
−0

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:

  1. 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.

  2. 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).

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »

This community is part of the Codidact network. We have other communities too — take a look!

You can also join us in chat!

Want to advertise this community? Use our templates!

Like what we're doing? Support us! Donate