I have developed a REST application and one of my application's case is that:
User makes an operation at server side. Everything goes well server accepts data correctly however some error occurs as like communicating with database. I don't want to return it with an error code I want to send it with a success code but has a body that indicates error. I want to send error codes for 500, 404 and etc. Is my design is correct and which status code should I return for my case?
Some kind of 5xx error would be the most appropriate in this case.
500 for some kind of internal server error or
503 for service unavailable
Look here for all the error codes for HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
You should always return an error code for your rest service if this is appropriate. Returning a success code but putting an error in your response isn't the right thing to do.
If the server's operation can recover from such a DB failure without the user's intervention (e.g. using some background "cleanup-process") then a success status code might be OK; otherwise, it makes more sense to return a server-side error status code (5xx).
That might help: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html - can be ambiguous at some places, but overall an easy read IMO.
You can check the status definition at the rfc2616
I used to implement rest aplication and I always returned a statuscode and a message with more info about the error.
And yeah for a problem with a database a 503 (service unavailable)
There are a lot of questions about this kind of topic at stackoverflow...
