Kent

I enjoy it.

Oh, wait, *that* REST. Well, I have no rights to dare to comment on what either Don or Dare have to say. So, here goes.

REST, like that other acroynym that has become trendy right about now is more attitude than architecture. I babbled for about 30 pages to create a chapter in a book I'm trying to drag myself through about it. Sure the samples I created were probably uber lame, but I'd like to think I stepped a bit into that mindset. I went in opinion from "huhn?" to "OK, I can see how this could work and scale quite well." to "This needs better tool support, and PUT/DELETE seems like too much work for what you get."

For the record, I used the terms "Pure" REST (what Don calls Hi-REST) and "Just enough" REST (for the variety of REST you can do from a browser). Obviously, there are *huge* amounts of applications that would benefit from a REST interface, otherwise we wouldn't be seeing this Web thing in front of us). Personally, I think that set is larger than the set of applications that *need* SOAP. Hmmm. Maybe I should phrase that better, as SOAP is fairly RESTy. I think that there are more applications that would benefit from being exposed in a REST model than need WS-*. Yes, some people will create "next generation completely distributed application with 4 separate partners, and ensure full transaction support across domain with built in security with each partner with logging and fail-over support". However, they'll also take longer to describe than write, and will likely fail, at least partially.

As I've said many times in the past -- look to solutions that work to define your own solutions. Oftimes the simplest solution is all you really need. Will you need a WS-Security communication channel, or will an HTTPS-secured POST to an end-point work just as well? One need only look to the slow migration of many Java developers from the increasingly immense EJB standard to slimmer solutions, such as Spring, Struts and Hibernate. While I have never seen the guts of Amazon, or eBay, I'm assuming that a lot of the communication with third parties is via HTTP(S). I refuse to believe that the logic behind these sites is that much more complex than most businesses need. How many Web services do you think MySpace uses to get the traffic they do?

I worked (rather briefly) for one of the "Big n" consultancies, and it freaked me out. My first assignment was to work on a number of "frameworks" (logging, authn, etc.) that would be used by the application. This was before the overall scope of the app was known, and before every other developer except myself and the Microsoft consultant knew the language it would be written in. Sure, the app was designed to be buzzword compliant, but all it *really* was (from my foggy hindsight) was a search that would push a document out to the client, then allow the client to edit the data, and send back. The architect wondered why myself, the MSFT consultant and other folk said, "OK, so you're building a Web app?" He had decided that he didn't need a Web app, because Web just wasn't buzzwory at the time, he needed a ESB/SOA/whatever-was-the-cool-acronym-at-the-time. Similarly, some developers and architects jump on a term, and decide they "need it" (including REST and Ajax, BTW). As Mike pointed out after the above quote I mocked, "Use the right tool for the right problem".

TTFN - Kent
[Nature Of Love - Cruelty Mix by Ministry]]
PS: I think the Amazon S3 service might be the closest thing to a "Pure REST" service out there, even though it doesn't support PUT.
PPS: Ironically, it was at least in part of my work at said consultancy, and my pushing of SOAP as the solution that I ended up at MSFT, and meeting Dan and Dare (and many others I worship). Funny little industry, isn't it?