none
Best Practice to return responses from services RRS feed

  • Question

  • I am writing a SOAP based ASP.NET Web Service having a number of methods to deal with Client objects. e.g:

     - int AddClient(Client c) => returns Client ID when successful
     - List<Client> GetClients()
     - Client GetClientInfo(int clientId)
    

    In the above methods, the return value/object for each method corresponds to the "all good" scenario i.e. A client Id will be returned if AddClient was successful or a List<> of Client objects will be returned by GetClients. But what if an error occurs, how do I convey the error message to the caller?

    I was thinking of having a Response class:
    Response { StatusCode, StatusMessage, Details }
    where Details will hold the actual response but in that case the caller will have to cast the response every time.
    Is there a better solution?


    -- Abhimanyu
    Tuesday, March 8, 2011 4:11 PM

Answers

  • No, it is not odd. It is C style of coding to express error as error code. When you come across an error you should throw exception (or fault in case of webservice).

    "Client Id already exists"- in this case you should definitely throw exception (or fault).

    "Could not find client with specified Id"- In this case you should return null value, if it is returning a object. You should not throw exception (or fault) in such cases.

     

    Yes this is right way if best practices in exception handling are followed.

     

    To avoid explosion of exception (faults) you can define the error code in them.  However some people prefer to define exception for all error reason. Here is an example for exception (you should be able to carry forward it in to ASP.NET fault as well)-

     

    public class ClientException:Exception

    {

            public ClientError Reason {get;private set;}

    public ClientException(string msg,ClientError reason,Exception innerException):base(msg,innerException)

    {

    Reason=reason;

    }

     

    }

     

    public enum ClientError

    {

           DuplicateId,

           ...and other code...

    }

     

    You can further look at following thread, it will give some idea about exception handling-

     

    http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/thread/dbf773d0-9ff0-4a26-adec-569b8d86a3cf

     


     


     

    Wednesday, March 9, 2011 2:39 PM

All replies

  •  

    I have worked with WCF not with ASP.NET WebService but fundamental approach to communicate error (Or Fault) over WebService is same.

    SOAP has the provision to communicate error as fault to calling party. Technically you will not return error as some kind of code. You should be throwing exception on service side and that exception will be communicated as fault to client. On client side you will handle that fault like normal exception. You need to explore technically how you can achieve it in ASP.NET Webservices (should be pretty straightforward).

    I hope you're aware that if you're writing new application, you should start with WCF not with ASP.NET Webservices.

     

    Gurmit

     

    • Proposed as answer by prasadpnvrk Sunday, March 27, 2011 8:53 AM
    Tuesday, March 8, 2011 5:41 PM
  • If the only communication protocol I want to support is SOAP over HTTP then what are the benefits of using WCF? I am not very much aware of the differences between ASP.NET WebService and a WCF Service but I know both are going to be hosted by IIS in my case.
    -- Abhimanyu
    Tuesday, March 8, 2011 5:45 PM
  • You should not consider only "Hosting" and "Http" for deciding between WCF and ASP.NET WebService. You can google about the differences between ASP.NET webservices and WCF.  WCF is coming with lots of goodies-

    -Multiple options for communication protocols. Why would you need HTTP if your client is .NET application? You will get performance boost when using TCP protocols with binary encoding. You can expose your service over HTTP and SOAP with almost no effort.

    -Security. I'm not sure how close ASP.NET can stand to WCF.

    -Federation. A big daddy in WebService collaboration. 

    -Extensibility

    -Future technology- Microsoft is investing in it and recommending it over ASP.NET.

    List does not ends here....any search engine will help you out..

     

     

     

     

    Tuesday, March 8, 2011 6:30 PM
  • Thanks for the information.

    Coming back to the original question, exceptions can be communicated via Faults (as you mentioned), and these faults will generate exceptions at client end but what about messages like "AddClient(...) Failed: A client with the specified email already exists". There is no unhandled exception in this case, the method call failed and we need to communicate this to the caller somehow.


    -- Abhimanyu
    Wednesday, March 9, 2011 8:43 AM
  • SOAP faults can carry other any serializable contents. You can put message or any other detail in SOAP fault you need. Please google for  "ASP.NET webservice fault", you will find tons of documents on how to do this. Here are some of links-

     

    http://msdn.microsoft.com/en-us/library/ds492xtk(v=vs.71).aspx

    http://msdn.microsoft.com/en-us/library/6d0x301k(v=vs.80).aspx

     

    Gurmit

     

     

    Wednesday, March 9, 2011 11:00 AM
  • It seems odd to me that failures like "Client Id already exists", "Could not find client with specified Id" etc will generate exceptions at client end. Do you think generating exceptions is the correct way to communicate this kind of failures?


    -- Abhimanyu
    Wednesday, March 9, 2011 11:17 AM
  • No, it is not odd. It is C style of coding to express error as error code. When you come across an error you should throw exception (or fault in case of webservice).

    "Client Id already exists"- in this case you should definitely throw exception (or fault).

    "Could not find client with specified Id"- In this case you should return null value, if it is returning a object. You should not throw exception (or fault) in such cases.

     

    Yes this is right way if best practices in exception handling are followed.

     

    To avoid explosion of exception (faults) you can define the error code in them.  However some people prefer to define exception for all error reason. Here is an example for exception (you should be able to carry forward it in to ASP.NET fault as well)-

     

    public class ClientException:Exception

    {

            public ClientError Reason {get;private set;}

    public ClientException(string msg,ClientError reason,Exception innerException):base(msg,innerException)

    {

    Reason=reason;

    }

     

    }

     

    public enum ClientError

    {

           DuplicateId,

           ...and other code...

    }

     

    You can further look at following thread, it will give some idea about exception handling-

     

    http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/thread/dbf773d0-9ff0-4a26-adec-569b8d86a3cf

     


     


     

    Wednesday, March 9, 2011 2:39 PM
  • Just to confirm what's already been said.

    From what you've described it should be an easy decision to choose WCF services as your best option.

    If there's still any doubt in your mind then you ought to go back and review the documentation on WCF.  It should be an easy choice.

    Wednesday, March 9, 2011 3:49 PM
  • If you don't know about SOAP then what about making it a REST API? Or a WCF REST? Or RPC? Does your service share session state with your web site? Is your service likley to be the end point of a SOAP discovery query? 

    Take a little time to weigh up your options, don't jump for any of them until you understand the cost/benefits of them with respect to your problem.


    http://pauliom.wordpress.com
    Wednesday, March 9, 2011 4:38 PM