On Nov 27, 2006, at 11:39 AM, Mike Glendinning wrote:
You are right that application/xml is a bad choice for a content type in a RESTful design. The Atom Publishing Protocol, for example, uses application/atom+xml. But even if application/xml is used, you can take a look at the XML root element and its namespace -- at least with a GET, you know it's safe to retrieve an example message using curl or wget :-)--- In [email protected], "Mark Baker" <[EMAIL PROTECTED]> wrote: >> There are many advantages depending upon what angle you're looking at> it from - caching, security, reliability, etc.. In general though, I > think the big one is that any HTTP client anywhere can turn that URI > into data using GET. If POST were used, then clients would also have> to know *what* to POST, removing that benefit. Coordination costs are> less (effectively zero) using GET. > > Mark. >But how do I know what to do with the data that is returned by GET?The content type probably just says "application/xml" or perhaps "text".
Are there not significant coordination costs in delivering (in advance) to every REST client enough information to decode and make sense of allpossible data formats, both current and future?
Not more than with any other approach ... Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
-Mike.
smime.p7s
Description: S/MIME cryptographic signature
