- From: Kris Zyp <kris@sitepen.com>
- Date: Sat, 15 Mar 2008 21:49:03 -0600
- To: "Laurens Holst" <lholst@students.cs.uu.nl>, "Eric Lawrence" <ericlaw@exchange.microsoft.com>
- Cc: "Web API WG \(public\)" <public-webapi@w3.org>, <public-appformats@w3.org>, "Sunava Dutta" <sunavad@windows.microsoft.com>, "Chris Wilson" <Chris.Wilson@microsoft.com>, "Zhenbin Xu" <zhenbinx@windows.microsoft.com>, "Gideon Cohn" <gidco@windows.microsoft.com>, "Sharath Udupa" <Sharath.Udupa@microsoft.com>, "Doug Stamper" <dstamper@exchange.microsoft.com>, "Marc Silbey" <marcsil@windows.microsoft.com>
> If XDR only supports GET and POST, it encourages sites to use POST to > implement delete functionality and abuse the HTTP protocol because that > is the only way they can get the functionality they desire to work. > Basically, you’re boycotting REST in favour of SOAP. I completely agree, it shouldn't be the place of the browser to dictate that developers they must use SOAP style instead of REST, and cripple the features of HTTP. The full features of REST (PUT and DELETE) weren't available in traditional web apps, but with Ajax, I belive REST techniques are rapidly growing in popularity, and will be particularly useful in cross-site scenarios because authors can leverage HTTP semantics to indicate meaning with different consumers/providers. I believe the same potential is possible with Accept headers, especially in the cross-domain world. Accept headers are not heavily used right now because in the dominantly same-origin request world because developers usually know a priori what content type is needed. On the otherhand, with cross-site web services, different consumers may desire different formats, and the Accept parameters could have awesome potential for allowing developers to request data in a desired format in well-understood manner. How foolish it would be to disable these features in the arena where it would have the most opportunity for benefit. I believe the full potential of HTTP has a great opportunity to be fully realized in the cross-site world where leveraging well-defined broadly understood HTTP features like REST semantics, content-negotiation, partial content transfer, etc. could vastly improve interoperability, by allowing consumers and providers to communicate with a rich set of well-defined capabilities. Crippling HTTP will force developers to use work-arounds which will only decrease interoperability and will ultimately cause increased use of hacks which will envitably subvert security rather than benefiting it. Trying to create a simpler more restrictive form of security does not mean things will be more secure. Developers use of cross-site scripts with callbacks to get cross-site data is great example of how an excessively simple security model has resulted in developers being forced to use dangerous methods to accomplish their goals. Thanks, Kris
Received on Sunday, 16 March 2008 03:50:19 UTC