Working with Web Services > Handling faults

Handling faults

Web Services sets HTTP status for all responses. Successful operations return HTTP 200. If the operation could not be completed for some reason, Web Services will set HTTP status to something other than 200, typically HTTP 500 (Internal Server Error). (You might also see HTTP 404, but this is an error from the Tomcat server indicating a problem with the URL, not the operation.)

It is good practice for your application to check HTTP status for all responses. If HTTP status is something other than 200, your application can process the content of the response for specific fault details if any.

For example, if you attempt a loginUser request with bad credentials, you will get a response like this:

SOAP example

HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Wed, 29 Sep 2010 20:02:37 GMT
Connection: close

<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns3="http://www.w3.org/2003/05/soap-envelope"><faultcode xmlns:ns0="http://schemas.sirsidynix.com/symws/exception">ns0:com.sirsidynix.symws.service.exceptions.SecurityServiceException.unableToLogin</faultcode><faultstring>Unable to log in.</faultstring></S:Fault></S:Body></S:Envelope>

REST example

HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 29 Sep 2010 20:06:01 GMT
Connection: close

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Fault xmlns="http://schemas.sirsidynix.com/rest"><code>com.sirsidynix.symws.service.exceptions.SecurityServiceException.unableToLogin</code><string>Unable to log in.</string></Fault>

By catching HTTP 500, you can then extract the fault code and string and take some action or display the fault string to the client user.

For information about specific faults, see Faults.

Handling JSON Faults

JSON faults need to be handled in a slightly different manner because faults for JSON are always returned with an OK HTTP 200.

An example fault response might look like the following:

{

     faultResponse : {

          "code" : "com.sirsidynix.symws.protocol.exceptions.HeaderException.badClientID",

          "string" : "Bad Client ID: SymWSTestClients"

     }

}

So, you should check to see if <responseVar>.faultResponse is an object type. If it is, then <responseVar>.faultResponse.code contains the error code and <responseVar>.faultResponse.string contains the error message.

If it is not an object type, then there is no fault and you can continue with the script.

Related topics 

 


© 2009-2012 SirsiDynix