rest - RESTful Authentication with Phone Number Verification Requirement -

rest - RESTful Authentication with Phone Number Verification Requirement -

how 1 handle restful authentication when authentication performed phone number must verified?

for example, let's user wants sign in. user nail endpoint phone number queue text message sent phone number verification.

in theory, 2 endpoints this:

authentication [post /users/authentication]

finds or creates user using phone number, returns user, , enqueues text message sent specified phone number (which delayed).

request (application/json)

{ "phone_number": "4151111111" }

response 200 (application/json)

{ "id": "85165292-8cce-42a3-960a-ffbc7dac987b", "name": "james", "avatar_url": null, "phone_number": 4151111111 } group verification

the user provides verification code sent in text message verify user requesting authentication valid.

verification [post /users/{id}/verification]

request (application/json)

{ "phone_number_verification_code": "1234" }

response 200 (application/json)

{ "id": "85165292-8cce-42a3-960a-ffbc7dac987b", "name": "james", "avatar_url": null, "phone_number": 4151111111, "auth_token": "ff6828134dd6b2d288qcb8f381b0657c" }

what idiomatic way of going verification in restful way? verbs correct? endpoint names correct? missing something?

some info missing in question. resource “user” created on server , phone number verified?

assuming ‘yes’. next scheme looks me:-

authentication

request

post /users/<uid>/phones { “phone”: “4151111111” }

response 201 (created) should used when new resource added. in case new phone number created 201 should returned.

read specifications more info http://www.w3.org/protocols/rfc2616/rfc2616-sec9.html#sec9.5

as per rest specifications, post method should add together sub-resource. , method should list out sub-resources under resource represented uri.

designing per these rest specifications, doing on same url should homecoming list of phone numbers. not mandatory should per rest semantics. request/response should this,

request

get /users/<uid>/phones

response 200 ok

{ “phones”: [ {“phone”: “4151111111”, “verified”: “no”}, {“phone”: “xxxxxxxxxx”, “verified”: “yes”}, … ] }

for verifications

now have resource @ server identified uri (/users//phones/4151111111). not verified. verify send post message resource directly. this

request

post /users/<uid>/phones/4151111111 { “code”: “1234” }

response 200 ok.

now on "phones" homecoming "verified": "yes". this,

request

get /users/<uid>/phones

response 200 ok

{ “phones”: [ {“phone”: “4151111111”, “verified”: “yes”}, {“phone”: “xxxxxxxxxx”, “verified”: “yes”}, … ] }

if "users" not created can utilize similar semantics users also. this.

get /users

post /users, payload add together new users. response 201 (created) etc.

update

in case user exist or new user, request without "users" in url this,

post /phones { “phone”: “4151111111”, "user": "james" }

response 201 (created) have take care whether user existed or not. when phone number sent matching user searched in db , based on different conditions may homecoming responses this,

case 1, user doesn't exist

http/1.1 200 ok { "rel": "/phones/4151111111", "phone": "4151111111", "verified": "no" }

case 2, user exist phone not verified

http/1.1 200 ok { "rel": "/phones/4151111111", "phone": "4151111111", "verified": "no" }

note response same in case 1 , 2. in case 1, user created on server.

case 3, user exist , phone verified

http/1.1 200 ok { "rel": "/phones/4151111111", "phone": "4151111111", "verified": "yes" }

in case 3 user exist , phone verified; client should send request instead of 1 time again sending post verification code. client should automatically redirect instead of user initiating post.

case 4, phone exist linked other user. in case homecoming error code or per application demands.

sending uri in response respects "code on demand" semantics of restful style. client doesn't need know before hand verify.

for verification, client post code received in text message uri returned in previous response. this,

post /phones/4151111111 { “code”: “1234” }

response 201 (created) new phone added or 200 desired response body.

rest authentication restful-authentication rest-security