This is actually a topic that is pretty interesting to me.
I think the main idea behind a good API error design is to give the user (ie other developer) information to be able move their resolution at least a step forward.
For example an error that gives you an opaque condition number an information to "please call our support" is pretty darn useless because now I am synchronously stuck waiting for some other person not under my control.
What helps me push my problem resolution further?
1. Is it me who did something stupid or is it the API that has a problem?
2. Is it the same problem I saw a moment ago or is it some different condition (an error/condition number might actually be helpful here)?
3. Where do I find materials that explain how to fix this particular problem or how to implement this functionality (for example link to a wiki page, code example, etc.)
1 comment
[ 1.9 ms ] story [ 13.4 ms ] threadI think the main idea behind a good API error design is to give the user (ie other developer) information to be able move their resolution at least a step forward.
For example an error that gives you an opaque condition number an information to "please call our support" is pretty darn useless because now I am synchronously stuck waiting for some other person not under my control.
What helps me push my problem resolution further?
1. Is it me who did something stupid or is it the API that has a problem?
2. Is it the same problem I saw a moment ago or is it some different condition (an error/condition number might actually be helpful here)?
3. Where do I find materials that explain how to fix this particular problem or how to implement this functionality (for example link to a wiki page, code example, etc.)