A brief history, if you will… the last few years has seen a very strong push towards “Web Services” … using XML and HTTP in order to provide application-to-application services. This push has spawned SOAP and XML-RPC, primarily, as ways to do RPC using HTTP as a transport and XML to encode the data. As well, we’ve seen the identification…
Dave’s strawman notwithstanding, there’s nothing necesarily unRESTful with using XML-RPC-encoding, SOAP’s rpc/encoded, RDF, TM, “doc/literal” domain-specific XML as the representation encoding. I’d argue that … in terms of RESTfulness … the most transparent, visible, unambiguous and resiliant formats are the best, but maybe that’s just me … a quick re-reading of Dr. Fielding’s dissertation about representations doesn’t constrain the formats.
As well, I would agree that a bottom-up standardization of useful literal-XML patterns is a good thing; anything to save us from more data- and content-type XML encoding; as Tim Bray said recently, “[…] it would appear that itís more valuable to know what something is called than to know what data type it is. Thatís an interesting lesson.” Don’t get me wrong, being able to trivially [un]serialize data-structures on the wire is useful. It’s may be just not the best way to go about building internet-scale services. What if your language doesn’t have unsigned types, for instance? Or you try to serialize to me a super-complex data-structure that my platform simply has no implementation of? I believe it’s better to let [the client] handle how I’m going to store data, and let us exchange literal- rather than encoded- content.
In any case, I would argue (and I have been increasingly, recently) that “REST” is the wrong marketing word for what you’re really talking about. I believe what you’re calling “Amazon, EBay’s and Flickr’s ‘RESTful’ Web Service APIs” are in fact not [necessarily] RESTful … I think it’s better to characterize them as SHARE — Simple HTTP API via RPC and Encoded data.
So, yeah, REST continues to be an architectural style. For a variety of reasons, the word REST has been co-opted to describe not-necessarily-RESTful things … SHAREd and SHARE-friendly APIs, specifically. Please join me in tilting against windmills^W^W^Wtrying to call things by reasonable names.
So, now, maybe Dave will entertain a question I have.
RESTafarians boast that there are RESTful web applications already online for
Amazon, , eBay, Flickr, and many others, but developers quickly figure out that
they donít get any benefit: each REST application requires its own separate
stovepipe of code support right from the ground up, because they all use
different content formats. If these all used XML-RPC or SOAP, there would be
many standard libraries to simplify the developersí work, and a lot of shared
code that could work with all these sites.
Is the bit that’s shared across all these sites the XML <-> object mapping only, or something more? What else are you thinking of? For bonus points, why are XML-RPC or SOAP required for those things to be librarized?
First off, please do look beyond the “there are only 4 [HTTP] verbs” aspect of REST. “Hypermedia as the engine of application state” is hand-in-hand with Constrained Interface as being fundamental to the RESTful web. As well, the GET/POST distinction is critically more important than…
The following is a message to the service-orientated-architecture yahoo group. It’s in response to a thread about standardized interfaces and protocol semantics. I don’t think it bring anything new to the table except my own understanding of some issues, but – especially since Yahoo Group’s search interface is so bad – I’m going to post it here in case other people find…