REST authentication representation from a browser

The company I work for have started to create RESTful services with most of the development being outsourced.

Our first service is for user authentication. When a user enters an incorrect username and password the browser receives a status code of 200 and the response body representation is:

{
    "state": "FAILED",
    "responseCode": 400,
    "timestamp": 1310378271300,
    "anies": [
        {
            "errorCode": "-6600",
            "errorType": "MSG_ERR_EMPTY_ACCOUNT_API_KEY",
            "translation": {
                            "lang": "en",
                            "value": "Pr开发者_C百科ovided login is empty"
                        },
            "property":"apiKey"
        },
        {
            "errorCode": "-6601",
            "errorType": "MSG_ERR_EMPTY_ACCOUNT_API_PASSWORD",
            "translation": {
                            "lang":"en",
                            "value":"Provided password is empty"
                        },
            "property": "apiPassword"
        }
    ]
}

The browser interacts with a controller which in turn calls a web service. We will have clients interacting with the services directly as well.

The representation above contains the state of failure (400), an internal error code so a client of the service can look up what the error is in a particular language and a translation of the error which the browser will use to display on screen. The "property" attribute is the form element/ parameter the error corresponds to.

This feels incorrect to me.

1. Should the browser receive a status code of 400 and then look at the representation why it failed?
2. Should there be a attribute for translated text or would it make sense to have the text already translated if the accept header is en, fr, etc?
3. Is there anything else anyone can suggest?

Thank you

See the answer here for why a 400 response might be the way to go.

The larger problem is that the status code is being returned as part of the content. I think it would make a lot more sense to return a proper 400 status for API calls, returning the details of the error in the content. Also, I think you're right that it makes more sense to include an Accept-Language header and return content in the requested language.

The service should not return http status: 200 ok because there was an error. It must return an error status code:

• 400 bad request means the request format was wrong, for example no username sent.
• 401 unauthorized means the username and password did not match, login failed, or on a different page which requires permissions, it means that you have to login first.
• 403 no permission means you are logged in, but you don't have the permissions to visit the current page.

REST has only status code recommendations by error handling, so everything further you return in the response body can be application dependent. Feel free to use responseCode: 400 in your error message format, if you are happier with that...

400 represents a bad request (see here). The usage is incorrect in this instance, the request was fine its just the user wasnt validated. I would return response code 200 with the details listed above.