Some of my API actions require SMS confirmation due to security reasons, like creation of payment and CRUD for scheduled payments.
Right now I just return an entity with AwaitingSMSConfirmation state and confirmationId.
And then POST /SMSConfirmation with one time password and id.
Is my decision with state correct? Is there any canonical generic RESTful way for this?
Best Answer
I don't know of any canon, and IMHO that approach sounds quite workable...
Since you're interested in a "RESTful" aesthetic, you might start from the first principle of "RESTful": "representational state transfer". The general emphasis in RESTful is to accomplish changes in the server by sending over the new state of the entity. In this case, you're changing the state of the ScheduledPayment entity from "AwaitingSMSConfirmation" to, say, "Confirmed". I think it's more RESTful to say:
Aside: You might find something interesting by searching on REST and email-based confirmation codes, e.g. https://stackoverflow.com/questions/6664154/restful-reset-password-and-confirm-email In that discussion, you'll see several variations, and IMHO all of them would be equally recognizable to a general audience of programmers.