Web service API Error Code?

When you design your web service API, how do you organize your error code?

I mean how do you keep track of your API error code so that you can avoid having two error code for the same error etc (there seems to be too many error code to 开发者_如何学编程keep track of???)

I would have two, as there are advantages to having two error codes (API and service ones):

• Security - you should not be pushing API/backend details through a service to a user/consumer when in production. Having two error codes means that someone who is trying to attack your backend via the service cannot use that information.
• Idenfication of area - with two codes you can see where (service vs. API) the error is coming from.
• You can change the backend, which may introduce new codes (or have new codes which conflict with old ones) and the web service remains stable and error codes keep working for your consumer.

At what points in your development artefacts do the error codes appear. I typically don't use enumerations in my WSDL (maybe I should) but I do have enumerations or static constants in my (Java) code. So if you keep all those together it's quite easy to scan the existing list before adding a new item. However, I'm not sure that avoiding duplicates is actually a good thing.

In the end, so long as you can reliably interpret the error code it doesn't actually matter if you do have duplicates. So

 10034  - disk full
 23487  - disk full

doesn't seem to do too much harm whereas if you had at different points in your code

 10034 - disk full
 10034 - invalid input

then we have a problem. Hence I tend to allocate ranges of error codes to different subsystems and let the subsystems devise their own codes. This means that there tend to be very few places where any given error code is used and hence a quick text search (or grep) for the error code gets me to the place in the code where the problem was reported.

Force your developers to explicitly get a number from a central location (could be a database sequence).

You could even exploit this further by providing a page on your Intranet where developers shoudl first fill in a description of the error before they get their error number. Put the error description in a database together with the error number. You can allow other people to extend this further and build your error documentation on top of this database.