Web services API architecture

Question

I've recently programmed a REST web service API that allows another website to sign-up for my website remotely.

I've programmed all the necessary validation and filtering in to the API.

My question is, should I now ensure that my own registration form uses the web service API when handling user registration?

The form itself already has the very same validation, but it would seem to be that it would be best if there is only one method that is ultimately responsible for validation/filtering.

That solution doesn't seem to be the best, either, though because I am now making a REST client to touch my own web services API from the exact same website.

The last solution that comes to mind is to put the validation on my user model, and throw an exception up the web services API when validation is triggered. Are there any downsides to this solution?

Answer 1

One of the major benefits of REST is to define a interface that a remote client can access easily with the minimum amount of coupling between client and server. This is very useful when you do not control the client. This allows you to evolve your server interface without breaking existing clients.

The REST interface should really just be a thin layer over your validation and registration logic. In theory it should be easy for you to re-use that logic in your own website without going through the REST api.

Your website is not on a remote machine and you have control over both the client and server portion so you are not gaining anything by going through the REST interface.