RESTful Web services and DAL

[Matthew Graham]

Hi,

I would just like to thank Doug for this excellent summary of the 
discussions so far.

    Cheers,

    Matthew

Doug Tody wrote:
> 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
>
>