4

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?

  • Why do you feel it could be inadequate? – JensG Oct 17 '14 at 12:30
5

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:

POST /ScheduledPayment/123
state=Confirmed&confirmation_code=1a2b3c4d5e6f7

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.