17
I am implementing a service from a website that does the following:
My website (A) connects to some external services provided by third parties (B, C and D) using webservices.
In fact A is a REST API in the backend that is accessed by frontend javascript. The frontend is not necessarily mine, the client can develop his own frontend by accessing my REST API if so he prefer.
Each user of my site A has a login and password on site B, one on site C and one on site D. Each of these logins and passwords of sites B, C and D are saved in my database, through a functionality offered to the user for this purpose. These logins and passwords are different from each other and different from the login and password that I use to log the customer into the site A.
There are some features that the customer accesses on my site A that depend on the integration with services B, C and D, and at this time the login and password of the respective integrated service is used.
Sometimes the login and password sent to B, C or D are wrong because my user (from site A) saved them incorrectly when using the functionality that saves these logins and passwords in the database.
Well, my question is what HTTP status code I return to the client’s browser when the login and password for the integration are wrong.
400 - Bad Request does not seem good because it is for malformed HTTP requests and the request received by my site A is well formed.
401 - Unauthorized doesn’t sound good because that would be for an authentication or authorization failure on the A site which is where the browser is connecting. It turns out that the authentication failure was in the integration with site B, C or D and not site A. In addition, in case of this code be applied, a header
WWW-Authenticate
should be present to allow the browser to (re)authenticate on my site, which makes no sense in my case.403 - Forbidden also does not seem correct because the client has yes access to requested functionality, the problem is only that it has not been configured properly.
404 - Page Not Found also not correct because the actual page exists and the customer should know this.
405 - Method Not Allowed also not correct because the HTTP method used (GET, POST, PUT, etc) is correct.
406 - Not Acceptable and 506 - Variant Also Negotiates also do not seem to be correct because it has to do with the negotiation content that has no relation to the problem occurred.
407 - Proxy Authentication Required also does not seem to be correct because it tells the client to authenticate in a proxy before trying the request again with site A. It occurs that the request with site A is valid and does not need any proxy, the problem is between A and B, C or D.
409 - Conflict also does not seem to be correct because this is in case of a conflict between two or more requests that change the server state.
412 - Precondition Failed and 417 Expectation Failed also does not seem to be correct because it has to do with the contents of the header of the request, which in my case have no problem.
421 - Misdirected Request also does not seem to be correct because this occurs when the server is not able to produce a client response, and this is not the case.
422 - Unprocessable Entity also does not seem to be correct because this is in case the request has some semantic error. Turns out the requisition is correct after all.
424 - Failed Dependency is used by Webdav in the PROPPATCH method to specify that changing a property failed because it triggered the change of another property and this other property failed, as in RFC4918. I think using this to represent a login and password error would be inappropriate.
500 - Internal Server Error is for when an unforeseen and untreated error occurs on the server, or for generic server-side errors. This is not the case.
502 - Bad Gateway also does not seem to be correct because this is to signal an invalid response from the integrated service B, C or D. It occurs that the response from B, C or D is valid, although it is an error response. It would make sense if the login and password were something private site A with one of these other sites, but in case I’m using a login and password given by the customer.
503 - Unavailable Service also does not seem to be correct because this is for when the server is congested or under maintenance, which is not the case.
510 - Not Extended does not seem to be correct because after reading the RFC2774, This has to do with extensions specified in the request headers. In my case there is no header with any relevant special property.
511 - Network Authentication Required also does not seem to be correct because this is for when a problem occurs with the client-side network infrastructure to get access to the site A. In my case, if the request came to site A, it is because it already has the access.
As for the codes 402 - Payment Required, 408 - Request Timeout, 410 - Gone, 411 - Length Required, 413 - Payload Too Large, 414 - Request-URI Too Long, 415 - Unsupported Media Type, 416 - Request Range Not Satisfiable, 418 - I’m a Teapot, 423 - Locked, 426 - Upgrade Required, 429 - Too Many Requests, 431 - Request Header Fields Too Large, 451 - Unavailable For Legal Reasons, 501 - Not Implemented, 504 - Gateway Timeout, 505 - HTTP Version Not Supported, 507 - Insufficient Storage and 508 - Loop Detected, these clearly have no relation to my problem.
There are some unofficial status used around, but none of them seem to suit either.
So none of the 4xx and 5xx official HTTP codes I found specified anywhere seem to make sense to my case. So, what should I do? What HTTP code should I use and why? If none of the official status codes are adequate, would it be better for me to invent one for that or force the use of some already existing ones? If you are forcing the use of an existing one, what it would be and why?
Furthermore, I note that this problem of mine must be something common and recurrent, and therefore should already be covered in some of the existing codes.
Another point is that I am not sure if it is a problem in the client (4xx) or server (5xx), since the client request could not be answered due to a problem in the integration in the server side (5xx)however the reason for this failure is because the client provided incorrect information (4xx), but this information was not passed by the client at the time of the request, but was stored on the server side (5xx).
Note 1: I am aware of the questions about storing customers' login and password for third-party services rather than asking them for each request and the security implications of this. However, what I’m asking has little bearing on this.
Note 2: Considering the comments and the two responses posted, I clarify that I cannot simply return 200 indiscriminately for any request to then impose on the client to interpret the answer to know if there was an error or not. Return a 400 for any and every error and expect the same from the customer is also out of the question. It is an important requirement that HTTP status code should be an informational code.
Note 3: For now, I am using a custom code 432 for this situation.
in my opinion, HTTP Status refers to your website, not the integrated services. If site A is working correctly, the answer should be 200, if there is any integration problem due to typo, your site A should inform your customer that the integration did not happen due to typo, and indicating that customer profile settings should be corrected. If you return a 4xx or 5xx error, it will indicate an error on your site.
– rmagalhaess
The answer seems simple to me - your site is the status reference. If functional (integration does not cause catastrophic failure) then you managed to manage the state:
200 OK
. If the integration makes the implementation of the action impossible,500 Internal Server Error
. (Edit) Ricardo’s point is perfect. Integrations are part of its application.– OnoSendai
@Ricardo Answering something with a "200 Authentication error" is a bit strange, don’t you think?
– Victor Stafusa
@Onosendai Um
500 Internal Server Error
asking the client to properly configure the login and password is not exactly what can be considered an internal error of the server.– Victor Stafusa
@Maybe I didn’t make myself clear. If the user credentials are wrong, and the remote service has not accepted them, this is not a mistake on your system - you need to implement a flow that fixes the configuration. Meanwhile, its application is still functional; You will need to guide the user through another process flow, but this does not imply an error:
200 OK
indicates that your application still works. Unless it is just a proxy.– OnoSendai
@Victorstafusa, the customer accesses your Site A, so whenever you’re online the response from your Site A will be 200. If the response of the other services is different, you indicate on one page the response of each service. If you "assume" the error of site B or site C, it is your site A that is in trouble.
– rmagalhaess
If your application, however, has no treatment flow to wrong credentials and catastrophically because of this, this is an application error (and
5xx
seems valid to me.)– OnoSendai
@Onosendai Ok, I edited the question to clarify this. Actually the A application has two parts, a REST API in the backend and the frontend. If it’s just for the API to chat with my front, I can put whatever code I want and that’s it, but my question is from the REST API point of view if used by other applications, which would be the most appropriate code.
– Victor Stafusa
@Ricardo See the last comment I made to Onosendai.
– Victor Stafusa
http://stackoverflow.com/questions/942951/rest-api-error-return-good-practices, same theme, has several responses and diagrams.
– rmagalhaess
I know it sounds fun, but I always consult the HTTP cats https://http.cat/ for this... The real answer depends a lot on how your will be standard client implementation, the consumer model of their service.
– Jefferson Quesado
This is a very heuristic question, its specific case is a method not commonly used. Well, in my view it is a fault of the 5xx server if it was not possible to communicate with the third party services to authenticate. However, if your service is working and the credentials provided by you are not being accepted by third party services, then it is code 4xx on the condition that the credentials have not been accepted and because they are incorrect or have been provided incorrectly.
– LeonanCarvalho
@Leonancarvalho Yes, in the first case you mentioned, a 502 solves. The second case is the problem I describe in the question. I also came to the conclusion that this is a 4xx because it is something that the client has to act on and the "fault" is his. Currently I put a custom code 432 for this situation.
– Victor Stafusa
Can 3rdparty Apis be configured by the end user or not? I mean, he can change passwords of A, B, C and D so possibly responsible for authentication failures?
– Guilherme Nascimento
@Guilhermenascimento Yes, the user configured their passwords for services A, B, C and D. However, to be honest, I am no longer involved with the project in question, but even so, I’m still curious to know what would be the best approach.
– Victor Stafusa
I’m not going to give you an answer because it’s just my opinion and I’ve been wanting to comment on your question for a while. I think that if the user after logged in to "A" accesses "B" and "C" and the panel "A" can adjust and the notifications messages with errors are reported to be of the 3rdparty, then it would be 403. But if the feed is a type of synchronization and the adjustments have to be made directly by panels in the 3rdparty then it would be 500, because for the server "A" the situation is unexpected and the process is indirect. I hope I’ve been able to explain my point of view :)
– Guilherme Nascimento