REST Fluff
As Roy Fielding is trying to explain REST yet again, I am hearing some absurd fluff here:
- REST/HTTP is a core layer in the Web 2.0 goo
- REST/HTTP is not reliable. We still need WS-* for that
- REST is good for machine to human interactions
- REST needs less client software to be written
- REST is simple
- REST has this nice clean URL patterns that are self-explanatory
- CRUD can't deal with business processes.
Holy crap.
REST is a term that should be taken behind the barn and shot.
90% of the people who use the word “REST” really mean “POX”. It means that they want to build the same kind of web services that many of us were building successfully in 1996. It means that they’ve given up on the non-interoperable “MS-” (oops, I mean “WS-”) stack.
[Reply]
Paul Houle
21 Oct 08 at 6:49 am
“REST/HTTP is not reliable”
I had that in one of my talks. I was able to fight most of it, but when the topic of governance and negotiating QoS came up, I was at a loss for words.
At least in Java land, REST is also kinda screwed because the open source servlet containers out there can’t support anything beyond Basic AUTH. Which is fine over SSL, but freaks out the security people.
Is there any standard protocol out there that people are using for non-html Web/RESTful apps?
[Reply]
subbu Reply:
October 26th, 2008 at 7:19 pm
As Paul Prescod remarked (http://www.prescod.net/reliable_http.html), reliability is a software issue, and I don’t see how one can’t negotiate QoS for HTTP based systems. Just because something has “Reliable” (such as WS-ReliableMessaging) in it and that there is no HTTPR (the store and forward idea that IBM tried once) does not make HTTP unreliable. HTTP provides simple techniques to make POST, PUT and DELETE reliable.
I think negotiating QoS goes into a similar bucket.
[Reply]
Bill Burke
23 Oct 08 at 2:23 pm