Re: [rest-discuss] Another REST vs. SOAP article
- Toivo "Deutsch" Lainevool wrote:
> I wouldn't stand up for monolithic services, but I will try to defendI think I could be convinced that a "generic objects" model has some
> the SOA approach a little. (Keep in mind that I'm not arguing that one
> of the approaches is "better", I think both have their appropriate uses.
> To me there is no clear winner. When deciding which is better to use in
> a particular system you have a lot of context to keep in mind. I'm just
> trying to get a better handle on some criteria to help me make this
advantages over a REST model in some circumstances but I really cannot
see _any_ virtue in the service oriented model over the generic objects
model. It seems to me to be just a "dumbed down" version of OOP (where
objects have a uniform addressing scheme and can be created and
destroyed at runtime). Perhaps that dumbing down has useful sociological
effects. Clearly SOAP and XML-RPC seem not to have suffered in
popularity for leaving out the concept of "dynamic objects" but it seems
a serious omission to me.
> One of the hardest things to do when designing networked systems isI'm not convinced that there is a correspondance between granularity of
> choosing the right abstractions (e.g. resources or services) at the
> right level of granularity. Systems that have abstractions that are
> too coarse grained end up pushing around a lot of unneeded data across
> the wire. If the granularity is too fine, too many messages go back
> and forth across the network.
addressing and granularity of messaging. One message could influence
thousands of addressable objects or thousands of messages could have
only a small effect on a single object.
> I don't think service interfaces need to be "monolithic". This justDespite what I said above, I can see how REST makes it harder to have
> seems like an issue of picking the right abstractions and granularity.
> To me it seems like picking the right abstractions and granularity
> would be more difficult with REST that with services. This is because
> resources are restricted to the HTTP verbs for interacting with the
> outside world, where with the service interface you are free to make
> up any verbs you want. So if you had a bank account that you were
> modeling, with a service interface you could do something like:
precise control over the granularity of messaging. You can't reasonably
have a method called "UpdateNThings" in REST, though you could emulate
it by POSTing an "UpdateNThingsRequest" resource. I would actually
rather compare SOA to "traditional, arbitrary methods OOP" because the
delta between that and SOA is smaller.
> Service: AccountYou call the service Account but it is really AccountManager in that it
> Has operation: deposit( account_number, amount )
> Has operation: withdrawal( account_number, amount )
> Has operation: calculateInterest( account_number )
> I wouldn't call this "combining a bunch of separate things". I would
> say this is grouping a set of related operation together in a cohesive
does not represent any particular account. That is nothing like OOP. In
OOP it would be:
Has operation: listAccounts() -> Account
Has operation: findAccount(account_number) -> Account
Has operation: findAccount(branch, customer_id) -> Account
Has operation: findAccounts(customer_name) -> Account
Has operation: createAccount(account_number, AccountData) -> Account
Has operation: destroyAccount(account_number)
Has operation: deposit(amount)
Has operation: withdraw(amount)
Has operation: calculateInterest()
This is a proper separation of concerns. Now we do not even have to
agree upon an account query model to share accounts. Similarly in a Java
program, you don't have to know how I created an InputStream to use it
as an InputStream. One library doesn't need to know the full details of
another library's interface to share objects. It only needs to know the
interfaces _of the objects_.
The mapping to REST is basically:
listAccounts -> GET /accounts
findAccount(s) -> GET /accounts?customer_name=...
createAccount -> POST /accounts returns /accounts/some_account
destroyAccount -> DELETE /accounts/some_account
deposit -> POST /accounts/credits (as per Dierkin)
withdraw -> POST (arguably those could be the same method)
calculateInterest -> (should this be a client service or embedded in
the server business logic???)
> It's probably because I've been using OO for a long time now, andIf you're used to OO then I would expect the service oriented way to
> haven't had nearly as much experience with REST, but it seems easier
> and more natural to do this the service oriented way.
feel odd to you. A 1970s Lisp or COBOL would totally understand the
service oriented interface as a functional interface. The key to OO is
integrating the data and the methods into separably addressable objects
with polymorphism. REST has that and more traditional web services
techniques do not.
> I suspect that the problem you have with the services style is thatIck, terminology is being misused. OOP is a programming structure
> it constitutes a collection of antipatterns for distributed OOP. If
> so, let's document what the risks of that style are.
paradigm dependent on such things as classes and inheritance. There
is no such thing as distributed OOP. Object-based systems is what you
get when you take OOD and distribute the objects. It is called
object-based (instead of object-oriented) because we are talking
about architecture, rather than source code structure, and architecture
doesn't have classes and inheritance.
> CommunicatingThat is difficult to do. The OOPSLA community took the architectural
> to the OOP world through patterns/antipatterns is a great way to
> make the case for the REST style - with the added bonus the claims
> for REST will seem less grand.
concept of patterns and expanded it into anything with a recipe for
implementation. I use the original notion of patterns, which came
from Alexander watching human behavior as people live/work/move within
a space. The closest analogy in computing is how data moves within an
architecture. In other words, I do explain REST as a pattern, but
what people call patterns now is tuned more for programming idioms
rather than understanding system behavior.
Architectural styles and architectural patterns are fairly consistent,
but as you noted the purpose of REST is to force the developer into a
less object-specific architecture, which is contrary to most of the
OOD patterns. Whether that is good or bad depends on what is
Roy T. Fielding, Chief Scientist, Day Software
2 Corporate Plaza, Suite 150
Newport Beach, CA 92660-7929 fax:+1.949.644.5064
Co-founder, The Apache Software Foundation