REST authentication representation from a browser

Question

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": "Provided 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.

Should the browser receive a status code of 400 and then look at the representation why it failed?
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?
Is there anything else anyone can suggest?

Thank you

I've posted the same question on the REST usergroup if anyone else wants to follow - http://tech.groups.yahoo.com/group/rest-discuss/message/17606 — Ilyas Patel, Jul 13 '11 at 18:44

score 1 · Answer 1 · answered Dec 02 '13 at 11:26

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...

SPOT ON!! For a REST api, never ever return a 200: OK status, unless it's really all OKAY... let's not screw up HTTP again, when something is definitely wrong... return the appropriate 4XX status codes. — vanHoesel, Sep 26 '15 at 19:33
@vanHoesel I completely agree. http://www.brandsoftheworld.com/sites/default/files/styles/logo-thumbnail/public/102011/like_icon.png?itok=nkurUMlZ — inf3rno, Sep 27 '15 at 00:46

score 1 · Answer 2 · edited May 23 '17 at 11:58

1

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.

edited May 23 '17 at 11:58

Community

1
1

answered Jul 13 '11 at 14:43

John Howes

245
1
7

Thanks John. Do you think it is still correct for the *browser* to receive a status 200 even though validation failed? – Ilyas Patel Jul 13 '11 at 16:58
I won't claim to have the correct answer here, but the way I do this in the browser is to do a redirect back to the referring URL with a flash message. So I end up with a 200 after the redirect. I think this is better for application flow than doing a 400, but others may have better ideas here. – John Howes Jul 13 '11 at 17:39
Here I'm only talking about a straight HTML browser experience. For ajax calls within the browser, I would do the normal 400 status and handle it with javascript. – John Howes Jul 13 '11 at 17:45

score 0 · Answer 3 · answered Jul 13 '11 at 13:15

0

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.

answered Jul 13 '11 at 13:15

Tom Squires

8,848
12
46
72

REST authentication representation from a browser

3 Answers3