Lecture 17: REST-Related Readings
Agenda
- Discuss REST-Related Readings
Need Volunteers: Lay of the Land
- Provides basic definitions and history
- Representational State Transfer (commonly REST) is a style of software architecture for hypermedia systems of global scale, [such as] the World Wide Web
- Roy Fielding iteratively and collaboratively developed the ideas of Representational State Transfer beginning in 1994, culminating in his 2000 doctoral dissertation, “Architectural Styles and the Design of Network-based Software Architectures”. In the dissertation, Fielding coined the term “Representational State Transfer”, chose the abbreviation “REST”, and defined REST with a set of architectural constraints.
- Has been completely rewritten (gutted) from a previous version. See for example http://en.wikipedia.org/w/index.php?title=Representational_State_Transfer&oldid=80925806. The current version is nowhere near as useful as the previous version.
- Previous version contained information that I reviewed in lecture 15.
- Written in March 2006
- Reports that developers of Web services (“Web applications that use open standards to interact with one another dynamically across heterogeneous systems”) fall into two camps.
- One group advocates using Web services to build complex internal systems known as enterprise service-oriented architectures (SOAs).
- The other seeks to use emerging Web technologies in tandem with Web services to create flexible external applications.
- The author, Daryl Plummer, sees Web services as distinct from middleware (which is a different perspective than the one presented in our textbook)
When it comes to building SOAs, I can't get over how much effort is wasted trying to force Web services to deliver enterprise-level capabilities they were never intended to handle. For example, managers at a well-known airline once asked me how to make their Web services provide an enterprise-level distributed-transaction environment, given the shortcomings of the Web services standards. "Did you consider using a real distributed transaction environment instead of Web services?" I asked. The looks on their faces indicated they hadn't.
- He also advocates that an organization should use the right tool for the job, don't shoehorn your problem into an inappropriate technology solution
I expect the enterprise-SOA camp to continue to grow rapidly, and the Web-technologies camp to provide immediate sizzle with some exciting new Web-services models. Either approach can be beneficial, provided that it's well-suited to your purposes. Beware of using an enterprise approach to deliver new Web functionality, for example, because it will lead to much less flexibility. And, don't even think about trying to use new Web techniques to run that airline reservation system.
Tim Bray, Part One
- WS-Angst: Written Feb. 22, 2006
- Starts by pointing at a Don Box piece called Pragmatics
- In this piece, Don Box (who is normally a strong advocate of the SOAP-based approach to Web Services), talks about how he resolved an internal (to Microsoft) debate about whether a product should adopt SOAP or REST
- His main point is that the two approaches are orthogonal, so choose the one that best suits your audience (which may require that you do both), avoid religious debates, and instead focus on shipping something.
- Next he points at Stefan Tilkov, who thinks the debate is irrelevant (Tim disagrees). Stefan's piece points to a bunch of pieces that Tim's did not. In it, one person (Mike Champion) implies that if you need to do heavy lifting use SOAP, otherwise REST is just fine. Stefan disagrees strongly with that statement. Stefan goes on to state “I’ve not seen any real-world deployment of any of the more advanced WS-* standards yet, and I have serious doubts that transactions or reliable messaging will be widely deployed soon”.
- That statement provokes a reaction by Chris Ferris (co-author of WS-ReliableMessaging) who states that he knows of several companies that are demanding the services provided by that specification, that a REST-based approach to the problem would not be as efficient, and that while things are taking longer than anticipated, things are just fine:
I will concede that it is taking longer than I might like to drive the WS-* specifications through the standards process. However, the reality is that standards take time to mature and vendors rarely implement until the standard is established (either de facto or de jure) and the market pressures are brought to bear. While Stefan doubts that transactions or reliable messaging will be deployed soon, the reality is that most vendors are actively developing the next generation of Web services capabilities in their offerings and I am confident that reliable messaging will be amongst the advanced WS-* features supported in most vendor offerings over the course of the next year or so. Once a certain threshold of vendor adoption and interoperability has been achieved, then you will see a sharp increase in the number of Web services deployments between, as well as within, enterprises.
- That statement provokes a response by Patrick Logan who says he was shocked by how little interoperability/functionality had been achieved in the WSDL/SOAP world and relates an experience using what he calls “real HTTP”
That last one about shipping something is interesting. In a recent experiment a small group and I found ourselves wrestling a lot with WSDL and SOAP (this was a dotnet *and* java experiment rather than a dotnet *or* java experiment). Wanting to quickly put that behind us, we decided to run a different experiment... address the same business problem but with just HTTP. Very soon we were spending all our time talking about business functionality and messages rather than infrastructure headaches. And yes, we could have at that time very easily thrown in LAMP, Lisp, Smalltalk, Erlang, etc. Anything that can do simple HTTP could be a full participant. The interfaces were narrowed and became a non-issue. The messages and the funcationality became the concern -- what is the business functionality? what is the message description? (We used xsd's and so I can attest to the above statement about schemas being independent of SOAP, WSDL, etc.)
- Dare Obasanjo weighs in agreeing with Don Box and Patrick Logan (WS-* interop does suck and its due to XML Schema) and points out that the fact that his bank uses REST to allow him to do financial transactions is a counter argument to Mike Champion's point about needing SOAP to do “heavy lifting”.
- The final word is given to Rob Sayre who interprets Don Box's original post in the following way:
- If you have Microsoft saying ‘well, the best approach is to make this elaborate infrastructure we’ve spent billions of dollars building out optional’, then the debate is over.
Tim Bray, Part Two
- Important, I Think: Written April 17, 2006
- Starts again with Don Box: Going Down to the Crossroads
- In this article, he outlines what Microsoft has done for XML/HTTP/REST technologies.
- In it, he makes use of the terms Lo-Rest (HTTP GET) and High-Rest (+ HTTP PUT/DELETE)
- Tim responds by saying that the label “Web Services” should be taken out and shot, and instead we should be talking about Web-Style applications. Web style is compatible with REST and includes
- You have a lot of things in the system, identified by URIs.
- The protocol (probably HTTP) only knows one MEP (message exchange pattern): single-request, single-response, with the request directed at a URI.
- An important subset of the requests, what HTTP calls GET, are read-only, safe, idempotent.
- You expect to ship a lot of URIs around in the bodies of requests and responses, and use them in operations that feel like link following.
He then says it’s here today, it works, it’s standards-based, and there’s a huge opportunity for building tooling and developer support around it.
- Don Box replies in HTTP, XML, REST, and $100, in which he asks, if I have 100 engineering dollars to spend on HTTP, XML, and REST, how should I spend them? He reports later in Spending the $100 that he didn't get much feedback because his use of the terms Lo-Rest and High-Rest apparently offended a bunch of people. Sigh.
- Tim Bray concludes by saying
Right now, a lot of people think that Web-flavored frameworks are the future of heterogeneous-network applications, which is to say almost all applications; and that the WS-mountain is really a WS-molehill; and that we need to fix up the tooling for developers.
David Heinemeier Hansson
- Routing around the WS-* vendor stacks: Written March 17, 2006
- An opinion piece that WS-* is “another ivory tower where no sane person wants to live!”
- This from the creator of Ruby on Rails and a co-founder of 37signals, a software company famous for making simple, high quality Web applications using REST
The Register
- WS-* vs the REST: Written April 29, 2006
- An interview with Tim O'Reilly and Jeff Barr (Amazon's Web services evangelist)
- O'Reilly thinks that WS-* is an example of “premature standardization” and says
Early in the web services discussion, I remember talking with Andrew Layman, one of the SOAP architects at Microsoft. He let slip that it was actually a Microsoft objective to make the standard sufficiently complex that only the tools would read and write this stuff, and not humans. So that was a strategy tax that was imposed by the big companies on some of this technology, where they made it more complicated than it needed to be so they could sell tools.
(!!!)
- Jeff Barr weighs in with
The trend is towards simplicity and getting applications running quickly. That implies away from SOAP and more toward REST, and even toward more lightweight protocols. There's a new protocol we're looking at called JSON, the Javascript Object Notation. Developers see the standards as helping them a little bit, but they're not all that put off if it's something custom. They want efficient development, efficient processing. It's approximately 20 per cent SOAP, 80 per cent REST.
The great thing about REST is that you can just demo it in the browser. Bring up the browser, you put a URL, you explain all the fields, you hit Enter, the XML comes back.
