Unique Constraint in a RESTFul architecture

Question

With 15 years of stateful client-server software development experience (and it's inherent problems) I'm still trying to grasp the concept of statelessness in a RestFul architecture.

Suppose I have a generic interface to post business objects to my REST service. For example User resources. My user resource should have a constraint on the uniqueness of his email address. My initial reaction would be to use the underlying database facilities to "garantuee" this. The second reaction would be to introduce some locking or transactional mechanism.

But my Restafarian collegue responds: 'No!' The client should check if the email for the new user is unique and you should just accept the fact that there is a small window of time in which a duplicate email address could be inserted. The client application should be able to handle this conflict.

This in turn goes against everything I have learned and doesn't feel natural at all. Please enlighten me...

Answer 1

I see no reason to not return the appropriate HTTP code: 409 Conflict. This can be returned upon getting errors from your database.

It is nice for usability reasons to check if the e-mail address is unique before sending the request as you can prompt the user (and disable submit) to correct the problem. In any case server side verification is still advised.