Mike Champion writes:
> Where I might disagree is using the label REST to describe the
> implementation of a *service* via HTTP: If the fundamantal
> abstraction is a "service", what value does the "resource"
> abstraction add here, and why is it useful to talk about exchanging
> a representation of the resource as opposed to invoking a service?
From a customer's or system integrator's perspective: I want to access
the service that tells me where my package is.
From the network architect's perspective: I've chosen to use REST. The
way REST models this is to provide a "resource" that has as its state the
location of the package, mint a URI a for that resource, and use HTTP GET
to get a representation that tells me where the package is.
I think you are going just a bit to far in identifying SOA with plumbing.
SOA is, I think, closer to what I've set out as the customer's and system
implementor's perspective above.
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
