Of course, I understand you can always rely on standard error codes for other standard problems, like 404 for not found, 401 unauthorised etc..

It is better to tell your client, it is not the culprit.

(2/2)

I'm enjoying this conversation.

To give more information on how usually most enterprise products work.

For every known error that can generate on server, there will be and error code with error message. These errors may not be due to client mistakes.

During this case, request will respond with.

Example response:
200 OK. This is to say your Http request is successful.
And response will include something like.

Error code: 156732
Error Message: There is an exception while accessing so and so. Please report to so and so.

Advantages of this.
*) Client knows error is not because of client side mistakes.
*) He/she can check official documentation for error codes related to that product.
*) When reporting issues, along with logs and traces, one can send error code received. This will help back end developers to isolate the issue immediately before debugging.
*) Products can translate such error messages based on locale of client request.

(1/2)

@maushax why do u suggest 403? It's not forbidden.

It's a valid request from valid client. As I mentioned before it's not client side error.

@norman70688 all 400 errors are client errors. Meaning client can correct and re submit, which is not the case here.

@gitpush

I understand response codes 400 and above.

Here the case is, all the params are fine, service is available, network is fine. But an error can happen on server side, even if everything is fine. For example, you've updated an object but there are inconsistencies that you observe while reading due to programming error or environment.

You can only use 200 status code with status and message in response. As far as I understand, 200 is used when server is sending intended response. It could be pass or fail with proper response.

@xorith I work for a big company, where there are more people for everything except development. Like 2 or 3 product experts, architect, product owner, scrum lead, UX guy so on. So many ppl wasting company resources.

It's up now.

If you're a developer, why are you gathering requirements? Why are you creating user story?
Don't you have product experts?

@BambuSource you can just Google. There are lot of examples.

Basically instead of waiting in uncertainty, use promises.

Let's say, u want to download a image.
Create a promise for the request.
There are lifecycle methods like then,done,fail which you use to define what you do when operation is successful or failure.

Just try some basic examples.
Here's explanation from Google.
https://developers.google.com/web/...

@norman70688 Yes. I explained every response code and when to use them.
Colleague was happy that I could make her understand.

@Drillan767 thanks. I was suggesting this to one of my colleague who was handling this request on server side.
But the guy who is working on client side, was demanding 500 code. This was because he assumes all failures will be 500. He handles only them.

I had to explain response codes.

You don't need delay, when you have promises.
Try them

@freeme it's a learning curve maybe. I just got surprised by the way we can use functions returning functions and how powerful it is.

W3Schools
https://www.w3schools.com

I also like this course.
http://lynda.com/course-tutorials/...