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.
Post History
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...
Answer
#1: Initial revision
by
Alexei
·
2022-01-13T15:08:17Z (over 2 years ago)
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.
1. `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).