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.Argument Exception: Cannot convert X to System.Int32.
Parameter name: type ---System.FormatEx ception: Input string was not
in a correct format.
at System.Number.S tringToNumber(S tring str, NumberStyles options,
NumberBuffer& number, NumberFormatInf o info, Boolean parseDecimal)
at System.Number.P arseInt32(Strin g s, NumberStyles style,
NumberFormatInf o info)
at System.String.S ystem.IConverti ble.ToInt32(IFo rmatProvider
provider)
at System.Convert. ChangeType(Obje ct value, Type conversionType,
IFormatProvider provider)
at System.Web.Serv ices.Protocols. ScalarFormatter .FromString(Str ing
value, Type type)
--- End of inner exception stack trace ---
at System.Web.Serv ices.Protocols. ScalarFormatter .FromString(Str ing
value, Type type)
at
System.Web.Serv ices.Protocols. ValueCollection ParameterReader .Read(NameValue Collection
collection)
at
System.Web.Serv ices.Protocols. HtmlFormParamet erReader.Read(H ttpRequest
request)
at
System.Web.Serv ices.Protocols. HttpServerProto col.ReadParamet ers()
at
System.Web.Serv ices.Protocols. WebServiceHandl er.CoreProcessR equest()

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*******@gmai l.comwrote in message
news:d7******** *************** ***********@a17 g2000prm.google groups.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].t hat.comwrote:

"Ben Joyce" <ben.jo...@gmai l.comwrote in message

news:d7******** *************** ***********@a17 g2000prm.google groups.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