POST to Create
GET to Read
PUT to Update
DELETE to Delete
Nothing strange about that. But how do we handle server-side data validation ?
Server-side validation cannot be replaced by client-side but it complements it. Client-side we can f.i. verify if an E-mail address is compliant with the SMTP rules but we cannot verify if the address is already registered in our database.
HTTP provides the error codes 4xx to indicate that something has happened:
400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict.
But how do we include enough information?
Inspired by the error validation model used in Spring MVC (Errors) I suggest that together with the 409 the server includes a response that may look like the following (assuming we are using xml):
<field name="email" rejected-value="an invalid email value" error-code="invalid"/>
<field name="username" rejected-value="robcos" error-code="duplicate"/>
Since the client can hold a reference to the object used for the POST/PUT operation, we may not need to include the invalid model in the response. The client should be able to show to the user an appropriate form with the validation errors.
Of course the errors tag could be extended to include more information to handle all the different cases but I thing that the idea is right (again, take a look at the Errors class in Spring MVC for an example of how to handle all kind of validation errors)