Best Practice for Web Service Design - Method Parameters and DataType Validation

[Ben Joyce]

Hi all.

I'm confused as to what the best or expected approch is to Web Service
design under .Net, mainly with regards to Methods and Parameters.
This is a bit awkward to explain so please bear with me.

I have a web service that needs to be accessed via GET, POST and
SOAP. The method expects an interger, a CustomerId for example, does
some processing and returns an error codeor 0 if no errors occurred.

Here's an example method declaration:

[WebMethod]
public int Test(int CustomerId)
{
return 0;
}

I noticed that if i pass a string to my method it would generate an
error:

System.ArgumentException: Cannot convert X to System.Int32.
Parameter name: type ---System.FormatException: Input string was not
in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options,
NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style,
NumberFormatInfo info)
at System.String.System.IConvertible.ToInt32(IFormatP rovider
provider)
at System.Convert.ChangeType(Object value, Type conversionType,
IFormatProvider provider)
at System.Web.Services.Protocols.ScalarFormatter.From String(String
value, Type type)
--- End of inner exception stack trace ---
at System.Web.Services.Protocols.ScalarFormatter.From String(String
value, Type type)
at
System.Web.Services.Protocols.ValueCollectionParam eterReader.Read(NameValueCollection
collection)
at
System.Web.Services.Protocols.HtmlFormParameterRea der.Read(HttpRequest
request)
at
System.Web.Services.Protocols.HttpServerProtocol.R eadParameters()
at
System.Web.Services.Protocols.WebServiceHandler.Co reProcessRequest()

This error description is returned with an HTTP error code of 500
which the client can trap and react to.

However the error doesn't say which parameter was passed the erroneous
data and as this all occurs before the method is entered and other
than the IIS web logs there is no way for the developer to log/review
what data is being sent to the method.

I've taken to declaring all the Method paramters as strings and
validating the data manually, a small and trvial step, and returning
the error (if any) as part of my XML response.

Is there anything especially wrong in building web services this way?
Any comments or suggestions appreciated.

Ben

[John Saunders]

"Ben Joyce" <be*******@gmail.comwrote in message
news:d7**********************************@a17g2000 prm.googlegroups.com...

Hi all.

I'm confused as to what the best or expected approch is to Web Service
design under .Net, mainly with regards to Methods and Parameters.
This is a bit awkward to explain so please bear with me.

I have a web service that needs to be accessed via GET, POST and
SOAP. The method expects an interger, a CustomerId for example, does
some processing and returns an error codeor 0 if no errors occurred.

Here's an example method declaration:

[WebMethod]
public int Test(int CustomerId)
{
return 0;
}

I've taken to declaring all the Method paramters as strings and
validating the data manually, a small and trvial step, and returning
the error (if any) as part of my XML response.

Is there anything especially wrong in building web services this way?
Any comments or suggestions appreciated.

Yes. Don't do that.

Your parameters should be typed appropriately. If the method operates on an
int, then the parameter should be of type int.

How did the client even manage to send "X" to the service? By directly
manipulating XML? Most clients won't do that.

If you will have clients sending random XML, then you can implement schema
validation and return details of the schema validation errors in a SOAP
Fault message. BTW, you should not be using return codes in a Web Service
any more than you should be using them in your code. It's too easy for code
to not check the return code, or to check it but do the wrong thing.
Instead, a Web Service should use the SOAP Fault mechanism, which will
translate to an exception in the client for most modern clients.
--
John Saunders | MVP - Connected System Developer

[Ben Joyce]

On Nov 7, 2:01*am, "John Saunders" <[e-mail]:

"Ben Joyce" <[e-mail] in message

news:d7**********************************@a17g2000 prm.googlegroups.com...

Hi all.

I'm confused as to what the best or expected approch is to Web Service
design under .Net, mainly with regards to Methods and Parameters.
This is a bit awkward to explain so please bear with me.

I have a web service that needs to be accessed via GET, POST and
SOAP. *The method expects an interger, a CustomerId for example, does
some processing and returns an error codeor 0 if no errors occurred.

Here's an example method declaration:

[WebMethod]
public int Test(int CustomerId)
{
return 0;
}
I've taken to declaring all the Method paramters as strings and
validating the data manually, a small and trvial step, and returning
the error (if any) as part of my XML response.

Is there anything especially wrong in building web services this way?
Any comments or suggestions appreciated.

Yes. Don't do that.

Your parameters should be typed appropriately. If the method operates on an
int, then the parameter should be of type int.

How did the client even manage to send "X" to the service? By directly
manipulating XML? Most clients won't do that.

If you will have clients sending random XML, then you can implement schema
validation and return details of the schema validation errors in a SOAP
Fault message. BTW, you should not be using return codes in a Web Service
any more than you should be using them in your code. It's too easy for code
to not check the return code, or to check it but do the wrong thing.
Instead, a Web Service should use the SOAP Fault mechanism, which will
translate to an exception in the client for most modern clients.
--
John Saunders | MVP - Connected System Developer

Hi John.

Thanks for the reply, most appreciated.

You asked:

How did the client even manage to send "X" to the service? By directly
manipulating XML? Most clients won't do that.

Well, the client app can send whatever they want via GET or POST so
what is to stop them sending "X" to a parameter defined as in int?
It'll generate the Exception and return text back to the client rather
than a specific error that could be handled. I see with SOAP this is
not the case, but for non-SOAP? What advised?

I'll look into SOAP in the mean time.

Cheers,

Ben