- From: Anne Thomas Manes <anne@manes.net>
- Date: Wed, 20 Nov 2002 15:46:04 -0500
- To: "Mark Baker" <distobj@acm.org>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Cc: <www-ws-arch@w3.org>
Mark Baker said: > > You snipped out the HTTP/WSDL bit. Do you agree that HTTP defines an > interface in the same way that a WSDL document does? No, I don't agree. The HTTP interface represents almost no semantic meaning. A WSDL interface can represent enormous semantic meaning. See Ugo's last message regarding the law of conservation regarding application semantics. HTTP has no knowledge of the contents of messages. SOAP/WSDL has extensive knowledge of the contents of messages. Therefore with SOAP/WSDL I can generate code to process my messages. I don't have to write all the code by hand. In many circumstances, I prefer to put some semantics into my interface because it makes the application development process that much easier. That's not to say that I don't like the REST approach, but I haven't seen an argument that works for me as to why it's so much better than the "abuse of POST" approach. I understand that REST takes better advantage of the power of the Web, and you can do things like create book marks and pass links, and cache results, etc. And these might be very desirable features in some circumstances. But from my perspective, most "real" Web services (filing my taxes online, submitting an insurance claim, ordering a thousand widgets, managing logistics, posting an email correspondence to my CRM system at Salesforce.com, etc.) will require SOAP headers for security, management, reliability, message coordination, etc. The REST approach can't address these requirements. Anne
Received on Wednesday, 20 November 2002 15:43:53 UTC