Choosing the right place to write logic in a client/api/server solution

Question

I'm currently designing a solution with this pretty standard pattern:

• 1 web-app using Django (it hosts the one and only DB)
• 1 client mobile app using AngularJS
• This client app uses a REST API (implemented on the Django Server with Tastypie) to get and set data.

As a beginner in these architectures, I'm just asking myself where the logic should go and I'd like to use a simple example case to answer my concerns:

1. On the mobile client App, a client is asked to subscribe by entering only an email address in a form.
2. a) If the address is unused, inscription is done (stuff is written on the DB).
3. b) If the address is used, an error is raised, and the user is asked to try again.

What is the workflow to perform these simple operations?

I'm asking for example how to compare the entered e-mail address in the mobile app with the existing e-mail adresses in my DB:

• Should I GET the list of all email adresses from the server, then perform the logic in my client app to state if the entered address already exists ? This seems really a bad way to do because getting lots of elements isn't performant with web services, and client should not be able to see all email adresses.

• Should I send the entered e-mail address to the server and let it make the comparison? But if yes, how am I supposed to send the data? As far as I know, PUT/POST are made to write in the DB, not to just send data to server to analyse it and proceed some logic.

I have the feeling I am clearly missing something here... Thanks a lot for help.

Answer 1

PUT and POST are designed to be used to create and update resources. The server may or may not have a database behind it. It might use a local filesystem, or it might handle anything in memory. It's none of the client's business. It is certainly common to have business logic on most servers which provide APIs.

Use PUT/POST to send up the email address to the server. The server checks to see if the email address is (a) valid, and (b) allowed. If it fails either check, return a relevant response to the client as documented in the RFC. I would go with 403 Forbidden, which indicates a problem with the data being sent up to the server. Use the entity in the response to detail what the problem was with the request.

Answer 2

I had done similar thing in a angular web app,

I have disabled the submit button, and added a check availability button beside the email field.

I have send the email to server and checked if it already exist and got the result to client, then asked the user to enter an alternate email if not valid or enable the form's submit button

Alternatively

when the user leaves the email field, You can send the email to a service that validates the email, and get the response, and show a message that this email already exist and disable the submit, or enable the submit button otherwise