Hi All -
I'll attempt to summarize our discussions to this point.
The DAL services (and other HTTP-based services like these) are "Web services" in the most general sense, but are not Web services in the sense of the more recent trendy notion of SOAP/WSDL based services which operate over Web protocols.
Matthew is correct that the DAL services, while they define a HTTP binding
which can have many of the semantic advantages of a REST interface,
are not REST services in the formal REST sense where generic operations
(verbs) are defined upon resources (nouns) referenced via URLs.
The formal REST concept is "resource" oriented. A "resource" is some
concept or entity which can be referenced by a URL or URI. This is
similar to the "file" concept in Unix. The generic operations defined
on such a resource are normally limited to GET, PUT (replace), POST
(update), and DELETE.
The REST model is resource or "file" oriented (in the most general sense of the term), but not "object" oriented. REST separates resources and actions as separate concerns, whereas the object model associates methods or operations with an object (resource).
REST has no use for a parameter-based GET since the latter is an operation or method performed upon some object, and conflates actions with resources. The advantage of the REST approach is that generic operations such as GET, PUT, etc., can be uniformly applied to any resource, and related resources can be used to describe the state of a more complex application or object. The disadvantage is that more complex object-specific operations are difficult to express in this model.
Nonetheless, a GET (or POST) with parameters is the most fundamental service operation in the J2EE (servlet) model, and is analogous to the method/operation/function in an object interface in any other technology. Most existing services are based on this model.
My conclusion is that while REST is a very powerful and fundamental architectural style, similar to the concept of a Unix file, the HTTP protocol also includes GET with parameters for good reason, and this construct is heavily used in the actual World Wide Web. The main thing we want to achieve with REST or HTTP is reuse of simple, elegant concepts and the associated generic protocols and tools, which can be achieved with either approach. Which is better depends upon what one is doing; we should not assume that REST is the "one true way", nor is the method-based object approach the "one true way" (apologies for the religious references but these things do sometimes seem to approach that level).
SOAP is more complex, and can do more for you so long as it does what you want. This is similar to the tradeoff between the deceptively simple but very general Unix models, versus more complex, feature-rich protocols designed for a specific purpose.