Re: [rest-discuss] Seeking some clarification around some aspects of REST
- Hi Peter,
On 11/15/06, Peter Madziak <peter.madziak@...> wrote:
> 2. A conceptual question: should I even think in terms of "a service" when it comes to REST? Is there necessarily always a "service" behind the RESTful interface that is processing the HTTP messages that are being sent to/from the RESTful system? I know that opening up the whole SOA versus REST question is a huge can of worms but I am trying to get down to even the most basic of questions: is the mental construct of a "service" a useful one when it comes to architecting my distributed systems using the principles of REST? Or is it better to say that the Resource is the conceptual primitive that I should be focusing on and that, as such, I should let go of any notion of service lingering from a numbers of years of being immersed in this thing called SOA?
I try to think in this way.
You have interesting data/functions that people want, so you start up
a service, provide an interface (hiding all complexity behind it) to
allow users to access your data/functions in a simple way.
*Interface* is like an abstraction of your service. So, how do you
model your service abstraction? E.g. to provide a web searching
If model it as a procedure call, your are thinking "I want to perform
a search, so I doGoogleSearch".
If model it in data-centric way, your thinking is "I want to get that
search results." Which search results? "The search results of
'beatles'! I have its identifier, here:
Recently I started to sense the HTTP resource abstraction model  is
like a network-based cousin of Unix file system (Container/directory,
readonly, read-writable file, Processor/executable file).
Teo Hui Ming
- Hi Teo,On Nov 30, 2006, at 10:54 PM, Teo Hui Ming wrote:That's an excellent question, and one I've wondered about as well.My answer (as usual) is "it depends" -- on what you mean by "service". If you think of a service as a purely abstract entity intended to *obscure* any concept of resources behind it, then that's probably an idea worth jettisoning. :-)If, on the other hand, you think of a service as "a collection of resources whose state can be manipulated", then I don't see any harm.-- Ernie P.