[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) wrote:
> I want to know what others have to say. I think
> you are saying that there is a complexity trade-off;
> that is, if you don't need a, b and c, REST
> is easier and faster to develop.
Thats certainly been my experience. We originally used
a lot of RPC-style XML over HTTP interfaces (nothing
I'd call RESTful), and then deployed a few SOAP interfaces
once the toolkits became stable (unfortunately not
before they were interoperable).
There was a lot more pain involved in implementing even
simple SOAP services, and debugging them once they were up
and running. We're now using RESTful APIs and
these have proved to be successful. They also feel
easier to work with: I've been merrily applying XSLT
to RESTful interfaces to generate HTML forms for
applications, shell scripts using curl to implement
management and testing tools. Feels a lot more agile.
Yes, there is more "roll your own" to REST, but one
needs to be clear about what that entails. A number of
our engineers were interested in using SOAP simply because
the toolkits offer Object-XML serialization mechanisms.
Once I suggested they use Castor, or similar APIs, they've
not looked back.
Also, once they've been shown one RESTful API, they've
been quick to get up to speed with others: the message
patterns are basically the same.
I've also noticed that our RESTful APIs promote a
better understanding of our internal models: rather
than a list of function calls, we're sharing resource
models. Not to be sniffed at for a small shop that needs
to be able to move engineers between projects easily.
2p worth duly spent,
Cheers,
L.
http://www.ldodds.com/blog
|
