views:

28

answers:

1

Recently I had to standarize communication between the client and the server in a rich web application composed mostly of widgets. Responses to the client are in a json format. When it was time to decide about handling error messages two ideas popped up.

  1. Send the errors message part of the response such as

    {"success":"false","errors":["field1":"message1","field2":"message2"]}

  2. Send the errors as a header and simply return false to client

response.addHeader('X-Application-Error','["field1":"message1","field2":"message2"]')

The second option seems to be neat; the user only checks for errors in the headers when they want to, the errors seems this way to be part of the protocol rather than be part of the response.

Is this a good practice ? Is one way better than the other.

+2  A: 

I would send error messages as part of the response.

Adding custom headers is what you'd do if you wanted to report things on the HTTP protocol level; HTTP already has established methods of reporting errors (via HTTP status codes). I would leave anything that's going to be shown to the client (or used by Javascript) in the body of the response.

thomasrutter
+1 I agree. Also, if you're returning errors messages to the client they should be in the clients language and not reveal sensitive info about your system (like DB connection strings) - just because you're expecting the calling code to be yours doesn't mean it always will be.
Adrian K
Ooops - "in the clients language" obviously applies to messages shown to end user; BUT - that idea also applies to exchanging any error info between different layers / systems.
Adrian K