16may2002

SOAP vs REST


paul prescod [REST], ?, rohit, sam ruby, dave winer, rael

[on my screen: the irc, a webcam from a different perspective, and my
notes...]

standard rest points: - http is well considered and large - sometimes
difficult to collapse transactions into this mode, ie from function call
to a rest way

this other guy i don't know: - successful because: rock solid, very
productive, "one of those pieces of code that doesn't break"

rohit: soap protects rpc when it goes outside your firewall

sam ruby: rest has been really badly articulate by the past three
speakers. what he's saying is 1 - there's get 2 - if you do something
which is a put or a post, but in the url, that's an abuse of the system.
the rest guys say you should only use GET when the url is simple and the
resource is idompotent. and use POST for databasey things. and the SOAP
guys say "and what, this weird rule for get/post is supposed to make
things more *simple*? why not just use post?"

dave winer: wants applications doesn't care about SOAP or REST, just
that people expose APIs in ways that programmers can understand

[the problem here is that REST is really difficult to articulate, and
really easy to get wrong.]

rohit is quoting from roy fielding's thesis which sets out rest. hey, i
should get hold of it, it sounds really good.

amazon/google are being compared as rest/soap, but people are saying
that amazon isn't really rest at all.

i love these terms: googley and amazonian.

argument is that rest is readable. but dave says soap is readable too.

[there's an enormous confusion because soap can be used for xml
documents, and for datastructures. i've a feeling the xml document
position will work really well if that's allowed in WSDL... but
otherwise it'll become just datastructures, and rest will be used for
xml.]

system architecture objection: the google soap model is an endpoint
thing. you connect to an endpoint and send some information. HOWEVER,
the way the web is built is that information is addressable. and the
website is like that. if the xml one could work like that, all the xml
technologies could be leveraged. but it can't be if we use soap.

this guy's argument is that the rest way and the soap way are
equivalent. [i disagree... if you use soap properly you don't need to
look at the xml at all.]

[sam ruby just said the google xml api never caught on.. but that's
because they were blocking ips.. well, that's not the only reason it
didn't catch on, but you know..]

there's loads of stuff specified in soap that isn't used: headers, etc.
people are still hung up on the objects binding to the protocol, and
then the messages are methods. --but what we're getting now is something
very different, and not very rpc.

the bit of soap that is representation state transfer [restful] blah,
methods etc. rohit says the most democratic bit about it is that every
pays the same text to use it.

rohit has: the uri is 1 dimensional SYNTACTIC SUGAR for passing a bunch
of methods in.

[nobody's saying that xml is ugly]


====

some notes about the future of soap from the osx/.net tutorial on
Monday:

sam ruby saying soap is just a data transfer thing it's going to be very
layered people are trying to do the layers too quickly

in the future there will be transactions etc built on top, but not in
the heart of it

wsdl is going to be a big part of it -- useful toolkit, not nec bound to
soap

most rpcs are tightly coupled -- server and client must be the same

but soap is looser. servers chooses whether to do anything on the
message

davidson saying: potential will be in new applications, not retrofitting
old messaging apps

ruby: if you can control both ends of wire, soap is better. if not:
loosely coupled, dynamic, member associations, etc