RESTful Web services and DAL

[Doug Tody]

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.

	- Doug