Today I watched an interview from QCON London with two ThoughtWorks employees who are involved in designing large scalable and cooperative applications. The basis for the communication that they use was simple web protocols over the HTTP 1.1 transport layer.
Some of the things I took away from the interview include:
- It is always a pleasure listening to architects like these guys because they are solving real problems rather than coming up with some beatiful abstraction.
- In solving the problems they are actually using there brains to solve the interaction problems rather than trying to force an abstraction to do something.
- They are writing a book called Web Based Integration.
- Asked the question is Web Based Integration REST? They responded, no. REST is a particular flavor of Web Based Integration, which they would hold up as being the most “webby” of the different styles. But because there are other constraints particularly already available implementation, that using REST may have to be moved toward, rather that cut over to.
- A common scathing comment is that don’t try for the “REST inside” sticker.
- Their premise is that the HTTP protocol is ubiquitous and can be counted on.
- Because it is ubiquitous you reap benefits from work done for other reasons such as caching, scalability, load management.
- When asked about tools they used they said that there were a lot of choices but that they sometimes (often?) found that using pure Servlets was the best choice for their projects. I understood that to include things like PHP pages because what they meant was that they used the raw HTTP mechanisms of their development stack. They had the interesting note that if you are more comfortable learning and navigating the abstractions of a framework that could be better for you, but for them they have spent that time learning the raw HTTP protocol. Seemed like a logical decision.
- They also talked about building a large “surface area” interface. Meaning that there were many “resoures” that were exposed for the use of other systems. This allows the system testers to interact with the interface and test individual pieces reather than a massive package. (It seemed analogous to the TDD guys talking about writing small methods that can be completely tested and have the work done by using many tested methods.)
- The definition of REST and Web Based Interaction was so good I’ll quote it here. This is from Ian Robinson.
It’s “pick your path to adventure for interesting business processes on the web”. We want to realize some goal having a couple of different things cooperating, we get to do that by serving up some HTML or some XML and the client or the consumer can begin, given a set of goals “I’m trying to achieve this thing or that”, it can begin to pick its path through the server landscape picking up on links inside those representations and working its way towards the goal.
This is not done in some automatic discovery sort of AI thing but rather is programmed in similar to the way we make use of this method then that method, etc. So the process would run something like, get this web resource, look for a certain piece of data, based on that data look for link one or link2 and then follow to get another web resource, etc. and when you are finished picking up the data you need you push it to this resource.
- I think that item (10) is the key to understanding the idea. Instead of making an interface which is made up of two or three items that front very complicated and convoluted processes, you instead build resources that do the individul parts and make those available. Then the client can change how they use the resources that you provide without needing to change the server. This is the same idea of loose coupling applied to application interaction that we try to apply to our code. I think it is safe to say that what make the interfaces we’ve created difficult is that they are fragile. A change here or there requires both sides to be changed.
- Another big find in this was a tool, a plug in for Firefox (Poster Plugin) that allows you to not only GET and POST from Firefox, but also to PUT, DELETE, etc. that gives us the tool to use a Web Based interface from the browser.
- Finally, are REST and SOAP different implementations of the same thing? This is my answer, SOAP is one of the abstractions that has been built on top of the transport layer and so can be used over HTTP, SMTP, etc. In practice it is usually used on HTTP. But it puts a whole lot of stuff on top. REST is just a style of interacting by making use of the HTTP protocol. It is not an abstraction but is a way to use HTTP. SOAP is the protocol; REST is how the protocol is designed.
By the way there is a transcript provided for the interview so you can skim it and not have to watch the whole thing.
Tags: REST, Web Based Interaction
