Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Another REST vs. SOAP article

Expand Messages
  • Paul Prescod
    ... I think I could be convinced that a generic objects model has some advantages over a REST model in some circumstances but I really cannot see _any_
    Message 1 of 50 , Nov 30, 2002
      Toivo "Deutsch" Lainevool wrote:

      > I wouldn't stand up for monolithic services, but I will try to defend
      > 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
      > decision.)

      I think I could be convinced that a "generic objects" model has some
      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 is
      > 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.

      I'm not convinced that there is a correspondance between granularity of
      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 just
      > 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:

      Despite what I said above, I can see how REST makes it harder to have
      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: Account
      > 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
      > unit.

      You call the service Account but it is really AccountManager in that it
      does not represent any particular account. That is nothing like OOP. In
      OOP it would be:

      Service: AccountManager
      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)

      Service: Account
      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, and
      > haven't had nearly as much experience with REST, but it seems easier
      > and more natural to do this the service oriented way.

      If you're used to OO then I would expect the service oriented way to
      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.

      Paul Prescod
    • Roy T. Fielding
      ... Ick, terminology is being misused. OOP is a programming structure paradigm dependent on such things as classes and inheritance. There is no such thing as
      Message 50 of 50 , Dec 5, 2002
        > I suspect that the problem you have with the services style is that
        > it constitutes a collection of antipatterns for distributed OOP. If
        > so, let's document what the risks of that style are.

        Ick, terminology is being misused. OOP is a programming structure
        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.

        > Communicating
        > 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.

        That is difficult to do. The OOPSLA community took the architectural
        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
        being implemented.


        Roy T. Fielding, Chief Scientist, Day Software
        2 Corporate Plaza, Suite 150
        Newport Beach, CA 92660-7929 fax:+1.949.644.5064
        (roy.fielding@...) <http://www.day.com/>

        Co-founder, The Apache Software Foundation
        (fielding@...) <http://www.apache.org/>
      Your message has been successfully submitted and would be delivered to recipients shortly.