none
WCF input validation best practice RRS feed

  • Question

  • Hi guys,

    I have a WCF service defining a number of methods, and i would like to validate all input (against say a regex)  to ensure all data getting into the service is valid.

    I use the various enterprise library validation attributes on the data contracts so that this can be handled relatively painlessly.

    What is the prescribed method for communicating any failures of validation back to the client? Is it possible that raising a fault is not the right thing to do (even raising ValidationFault, no matter how applicable it may seem!) as this is using exceptions to control program flow?

    If this is not an acceptable manner of communicating validation failure back to the client, then what is the recommended practice?

    Thanks for any help guys, will be much appreciated!

    Nick

    Wednesday, September 15, 2010 10:31 AM

Answers

  • Well the problem with not using a fault is that unless the client checks the return object they will have no idea that their request did not succeed.

    The client has specifically asked the service to perform some action on its behalf. The service has failed to do that - you should return a fault


    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Wednesday, September 15, 2010 12:36 PM
    Moderator
  • If you control the client, then obviously you would like to enforce data validation before making the remote call, but this is not always the case.  I wouldn’t regard data validation a process flow issue; it’s more of integrity enforcement.  After all, you aren’t looking to throw a fault to trigger an alternate business flow.  In this case, you are looking to return to the client enough information on their data issues so that they can resolve and handle the situation on their side.

     

    I believe returning a declared fault is the best practice when notifying the client of exception flows/issues; in this case data integrity failure.  So as a best practice, I would look to return declared faults where possible, falling back on undeclared faults as a catch all.  You can read more on this here:  http://msdn.microsoft.com/en-us/library/ms733721.aspx.

     

    This article will give you details on implementing the declared faults in your contracts:  http://msdn.microsoft.com/en-us/library/ms733841.aspx.

     

     

    Wednesday, September 15, 2010 12:36 PM

All replies

  • Well the service is being invoked incorrectly therefore it should return a fault. You can send back all the validation failures in a single fault to aid the client


    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Wednesday, September 15, 2010 12:11 PM
    Moderator
  • Hi Nicksta,

    Have two fields in the return object of your method. 1. ErrorCode/Severity and 2. Text.

    Let the method return ErrorCode/Severity as 0 for Sucess and other value like mentioned below for specific exception/validations types:

    1 for Exceptions
    2 for Warnings
    3 for Data related issues
    4 for Validation Failures
    5 for XYZ issues
    and so on...

    Hope this helps

    -Mohammed Ghouse Ibne Barq Kadapavi
    https://sites.google.com/site/barqkadapavi
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful.

     

    Wednesday, September 15, 2010 12:33 PM
  • Well the problem with not using a fault is that unless the client checks the return object they will have no idea that their request did not succeed.

    The client has specifically asked the service to perform some action on its behalf. The service has failed to do that - you should return a fault


    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Wednesday, September 15, 2010 12:36 PM
    Moderator
  • If you control the client, then obviously you would like to enforce data validation before making the remote call, but this is not always the case.  I wouldn’t regard data validation a process flow issue; it’s more of integrity enforcement.  After all, you aren’t looking to throw a fault to trigger an alternate business flow.  In this case, you are looking to return to the client enough information on their data issues so that they can resolve and handle the situation on their side.

     

    I believe returning a declared fault is the best practice when notifying the client of exception flows/issues; in this case data integrity failure.  So as a best practice, I would look to return declared faults where possible, falling back on undeclared faults as a catch all.  You can read more on this here:  http://msdn.microsoft.com/en-us/library/ms733721.aspx.

     

    This article will give you details on implementing the declared faults in your contracts:  http://msdn.microsoft.com/en-us/library/ms733841.aspx.

     

     

    Wednesday, September 15, 2010 12:36 PM