As demonstrated, Web services can return many types of data. This is because Web services are built on top of XML, which is very powerful for representing data. Even though XML is text-based, it uses a type naming system that allows other applications to determine data types easily. For example, you know that DataSets are fundamentally represented as XML data in a computer's memory, so it's easy to extrapolate that a DataSet can be sent via XML. XML also has representations for strings, integers, arrays, and DateTimes, among other things. Table 16.2 lists the various data types that Web services can transmit. Table 16.2. Supported Web Service Data Types Type | Description | Arrays | Web services can send arrays of any of the types described below, including DataSets, primitive types, classes, and XmlNodes. | Classes | Classes with public properties. | DataSets | The DataSet is internally represented as XML by ADO.NET, so it can be transferred by Web services. Note that DataSets are the only ADO.NET data stores that are transferable. DataReaders and such are not. | Primitives | Primitives include byte, Boolean, char, DateTime, Decimal, Double, GUID, int32, int16, int64, single, uint16, uint32, uint64, and XmlQualifiedName. | XmlNodes | The .NET XmlNode class, an in-memory representation of XML data. See Day 11, "Using XML in ASP.NET." | A Web service can return all the types described in Table 16.2, but it's more restrictive about which types it will accept as parameters. When you use SOAP to pass commands and parameters from the client to the service, you can use any of the previously described data types because SOAP is based on XML. If you use either Http-Get or Http-Post, however, you're restricted to the types that these protocols can handle. That is, you can use a subset of the primitive types and arrays of primitives. Http-Get and Http-Post are also restricted to sending only name/value pairs, which excludes more complex types of data such as classes or DataSets. |