0

I have an user authentication API which returns an object containing some data including status code, for ex. 200.Even if the credentials are incorrect i am sending 200 status message but the response object's status field has status 401 and message "Incorrect Credentials".So my question is, which response is proper?The one where even when the credentials are incorrect i am sending 200 status message and then inside the response object i have to check again for whether the credentials were correct or not or second where if the credentials are incorrect i am sending status 401 along with the response object?

Vallabh Lakade
  • 722
  • 7
  • 22
  • 1
    refer http://stackoverflow.com/questions/1618733/signalling-authentication-failure-in-a-restful-api – Lovababu Padala Nov 04 '15 at 11:59
  • There is no API for authentication in the link above, but i have and i am not sure which is the proper way to send the response. – Vallabh Lakade Nov 04 '15 at 12:17
  • So my question is, which response is proper? is this not your question. – Lovababu Padala Nov 04 '15 at 12:28
  • I agree with Lovababu that your question indicates that you don't have a problem with the actual authentication api, but you are instead asking for the proper HTTP status code. Therefor I agree with his link above as that should give you a hint. For further informations regarding authentication and HTTP status codes I recommend this document: http://tools.ietf.org/html/rfc7235#section-3 – BeWu Nov 04 '15 at 13:33
  • ok so i believe i will have to send a 401 status message.But do i have to do it with other APIs.Like if i have a parameter whose value is invalid,then i will have to set its response status to lets say 500, or just send 200 status code and then in the response the actual message that the parameter is invalid?For other APIs do i need to use the same way? – Vallabh Lakade Nov 05 '15 at 06:45

2 Answers2

0

I think it's better to return it in the HTTP header. In this way the client can know that an error has ocurred in an easier way. In the end it is more straightforward.

reos
  • 8,766
  • 6
  • 28
  • 34
0

Preferable way is propably to return the http status and code in the header. This way the user can use native methods to react to the responses. In case there is a unexpected error in your service and you cannot form a pretty response object out of it, the user is still able to handle it since the response will have the proper HTTP status code. If the user always expects your API to return an object, he/she is in trouble in that situation. Of course, you could tell them to take that into account, but then the user would have to implement additional logic to handle two kind of responses.

But:

You could do something like I did: Let the user choose!

I put a variable in the url that tells the service whether to return the http response with proper codes or not. The url looks something like this:

/some_path/{real_http_code}/some_path_or_data

Where the {real_http_code} is a true/false -text. If it's true, our service knows to return the response with the proper HTTP status code. If false, service will always return 200 OK -response, and the user has to check the response if something went wrong. So, the url could look something like this:

/some_path/true/some_path_or_data

Ups and downs:

+Gives the user the freedom to choose

-Additional logic must be implemented into the service

GotBatteries
  • 1,346
  • 1
  • 19
  • 28