다음을 통해 공유

Faults and HTTP

  • 아티클

I left HTTP error codes out of yesterday's post on zen faults because they're representative of a distinct class of out-of-band fault messages. Out-of-band faults map fault information to a transport-specific mechanism that carries the data outside of the normal message payload. Although we don't send a regulation SOAP fault message, there's still a clear concept of a message and the other side doesn't have to rely on intuition to know that a fault took place.

In the case of HTTP, the first line of a response contains status information that can be used to signify an error. There is a tradeoff to using this mechanism because SOAP faults are significantly richer than HTTP status codes while HTTP status codes are much more broadly understood by devices and programs. The status codes we care about lay in the 400 and 500 ranges. Codes in the 400 range are used for client errors and codes in the 500 range are used for server errors. Code 400 represents a generic error with the client request with additional definitions for codes 401 through 417. Similarly, code 500 represents a generic error happening on the server with additional definitions for codes 501 through 505.

A code 400 error would represent something like an uninterpretably mangled request message. The common code 404 (Not Found) error represents EndpointNotFound while the much less common code 415 error (Unsupported Media Type) represents an InvalidContentType for the SOAP message.

A code 500 error would represent something like a catastrophic service error, such as the code for the service can't be compiled. The only other common server error is code 503 (Service Unavailable). Code 503 errors typically represent unavailability due to server load, roughly the equivalent of ServerTooBusy.

Next time: Designing New Faults

Comments