0

I have a web app with JavaScript front-end which communicates with back-end via REST API (AJAX calls). Front-end have a Sign Up page. When user decides to register, front-end makes REST call to register that user (POST request sent to /users resource URL).

Users can also login/register via Facebook. When someone choose to login via Facebook my app don't know if user is already registered or I should register him. For now I have a simple implementation of that process. When someone logs via Facebook:

  1. HEAD call is made to check if user exists in users collection (HEAD /users/id)
  2. If user does not exist, POST call is made to register new user.

What I don't like about that solution is that:

  1. Two calls need to be made to check if user was registered and then register that user.
  2. When I make HEAD call to check if user exists and user does not exist I get 404 logged in JS console. It is normal situation when user does not exist (was not registered before), but when someone looks in the console it may seem like something went wrong.

I could skip HEAD call and make one POST call and when it turns out user was registered before I can return 409 from POST REST call. I still don't like that approach because I still would have an error in JS console (409) and second bad thing is that POST register request would be sent everytime Facebook user logs in even if he was registered before.

I've looked into some big websites and they seem to have one AJAX call when signing uin/up via Facebook. Adding two separate paths: sign up via facebook and sign in via Facebook will not resolve the issue since usually when someone choses to login via Facebook every page internally redirects to sign up process and I want to do such thing.

So my question is what is the best way to design such communication from REST APi side?

Improve this question
4
  • 1) can you just keep state in the browser (cookie, local storage) to keep track of if the POST is needed? 2) is sending the POST each time really that bad? Even if they're already registered and logging in, you'd have to POST a username/email + password
    – sea-rob
    Commented Jul 22, 2016 at 20:41
  • How do you determine ID (for HEAD /users/:id)? Is it something you generate, and if so how do you normally associate it with a facebook oauth callback?
    – Paul
    Commented Jul 22, 2016 at 20:47
  • @Rob 1) I could and it sounds like a good idea, but first I'd prefer a solution on a REST API side. 2) If user is already registered and logging in then I don't make any POST call. Facebook deals with usernames and passwords. I just get back info if user provided correct credentials and I get user id. Then I mark that user as logged in in my app and that's all. Additionally, I don't want to send POST requests everytime, because it doesn't look good for me from a logical point of view, because it would mean sending bulk of requests contradicting real semantic meaning (register when logging in).
    – ctomek
    Commented Jul 22, 2016 at 23:32
  • @Paul I get user id from Facebook API after user logs in via Facebook OAuth (via Facebook popup window). After user is logged to Facebook I get that id and I make HEAD call to check if that user is present in users collection.
    – ctomek
    Commented Jul 22, 2016 at 23:36

1 Answer 1

Reset to default
1

Ah, I see. This sounds like a PUT request would be the way to go, then. Semantically, a PUT request is made when you know the resource URL you're going to hit, and you want to either create or update the resource at that URL.

Alternatively, have different endpoints based on whether a user is registering or logging in (which is how most sites do it).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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