[
Lists Home |
Date Index |
Thread Index
]
4/13/2002 10:32:10 AM, Bill de hÓra <dehora@eircom.net> wrote:
>
>In fairness the technical people driving the SOAP standard see the
>distinctions. The main argument against REST for application comms,
>as opposed to application-people comms in my mind is to do with
>data typing.
For the record, I'm objecting to the idea of killing off HTTP,
not of using SOAP. SOAP is valuable for packaging data in a standardized
way, describing data types without the full overhead of XSD, describing
data structures that XSD can't, etc. This value can be used in
both the RPC and REST (and other) messaging models. "SOAP" is
used by the REST people to describe what they're opposed to, but I
think this is a shorthand for "SOAP using the RPC message pattern
that either assumes synchronicity or uses a non-RESTful notification
mechanism to handle asynchronicity" and not a reference to the actual SOAP 1.2
specification. And also for the record, Mark Baker is one of the
"technical people driving the SOAP standard", and works very hard to maintain the
distinction between "SOAP" the message envelope protocol and "SOAP" the way of
using RPC over HTTP.
>I was trying to figure out what a REST setup would look like in a
> The idea of using few but
>well known verbs is speech act theory for the rest of us, but you
>see thr idiom in everyday OO code as well as get/set methods.
This is a bit over my head, but I think I agree. REST gives OO
designers a standard set of persistence operations (?) and XML
means that the data can be exposed rather than encapsulated,
making it un-necessary to define all those get/set methods that
make OOP tedious. Perhaps this frees up designers and programmers
to focus on the business logic / actual value added rather than
the mechanics of data manipulation and persistence. More or less?
|
