REST Redux

The Rise of REST! I’ve noticed an increasing number of “What is REST?”, or alternatively, explanations of REST appearing lately. Most attempt to compare REST to SOAP which is basically the wrong argument. SOAP and REST cannot be directly compared, though for the last seven years it has been. Keep in mind that REST does not mean exclusively HTTP. Just take a look at the Java content-management standards JSR 170 and JSR 283 for an example of an API based on REST using Java.

Before I attempt to put my own spin on what and why you would use REST; If you are interested at all on Software Architecture, then I highly recommend that you take the time to read Roy’s dissertation – maybe even twice. It is a tour-de-force of what Software Architecture is. And if you feel really brave read Rohit’s companion dissertation.

Why base your software architecture on REST?

The high-level answer: When you don’t “own” each component along the wire it is important that each component be allowed to evolve independently. What matters in this context is the ability to work with components at different levels of implementation. That means constraining the interface to a commonly agreed standard so every component along the wire can understand what it means to GET, PUT, POST, DELETE etc.

Secondly no matter how fast the wire becomes we are still constrained by the speed of light i.e. there will always be latency. To combat this you end up using a course grained Document-Centric mode of interaction – sending HTML/XML/JSON documents etc – instead of a fine grained Control-Centric mode. The latter is RPC the former REST.

To make sure that each component knows what is being talked about it needs to be identified. Hence URIs identify a Resource. Response meta-data describes the context of the document that was returned. [in REST terms the context of the Representation returned.]

A Resource can be thought of as an object that implements various interfaces. It is a concept, a notional software component that implements many interfaces. In REST those interfaces are identified by URIs.

Without constrained interfaces, a data-centric mode of interaction and identity, caches won’t work for example. This also means that Hypertext now becomes the engine of application state. Every component interface implements a state machine regardless of the underlining component technology, hence in REST URI become a way of making the application state explicit. Tim Ewald framed it nicely:

“The essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you’re moving to, making that your new state. A state’s representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app’s protocol can’t work that way too. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)”

RPC (and therefore SOAP) rely on tool support to be vaguely usable. REST works because humans can do a wget and see what comes back. That reduces the coordination costs of building systems.

If you control all the components in the chain and you release them all at the same time and there is no latency issue to worry about, use a RPC style of interaction. Otherwise use REST. In today’s Web2.0 climate that means using a REST style, as a minimum, for externally exposed Resources via APIs.

An Architectural Style

REST is an Architectural Style in the true sense of Alexander’s patterns, compared to, the more prescriptive approach adopted by the Design Patterns movement, lead by the Gang of Four. SOAP is a XML language for specifying and constructing messages for a network protocol. The typical message exchange pattern is modelled after the RPC style. So just to confuse the matter SOAP can be compared more directly to HTTP; the latter being a Network API that attempts to conform to the REST style.

If REST is to be compared then it should be compared to RPC or SOA. Both are approaches to software architecture. SOAP is an implementation that can be used in either a Control-centric (RPC/SOA) style or a Document-centric (REST) style. It just happens than most uses of SOAP are RPCs.

No comments Digg this

Offline Web Apps now a lot more achievable

Early last week the Dojo Toolkit launched a toolkit extension for making the development of offline web applications a lot easier. From the launch announcement:

“Dojo Offline is a free, open source toolkit that makes it easy for web applications to work offline. It consists of two pieces: a JavaScript library bundled with your web page and a small (~300K) cross-platform, cross-browser download that helps to cache your web application’s user-interface for use offline.”

The 300K download is actually a locally installed web proxy that makes the detection, caching and online/offline transitions seemless. Part of the approach is to define a framework for handling the connectivity so that it is as easy and transparently from an end-users’ perspective. This includes a Dojo UI Widget that detects the presences of the Offline Proxy, prompting the user to download and install it. Being only 300K makes this a very quick process. If the proxy is installed then the widget will indicate the “connected” status.

This checking of connectivity goes beyond local network connectivity, by sending pings out across the Internet, it actually determines if Internet connectivity is present. This avoids the trap of being locally connected but globally disconnected.

From a implementation perspective the local proxy will cache all those files (XHTML, CSS, Javascript) to ensure that the Web application will still operate even if started offline. Once online the Sync component of the toolkit kicks in, performing a transparent merge operation with the back-end. The reason it is transparent is to avoid confusing the user. Instead the approach is to perform the sync transparently but let the user view the audit log of what happened if they wish too. Most won’t.

The Offline toolkit extends the Dojo offline storage engine. A portable, browser and OS, storage engine. Basically if you are using Firefox 2.x, then the storage engine uses Firefox’s offline storage capability, otherwise it uses Flash as the storage engine. This functionality has been in Dojo for sometime, so is well baked.

At the Web 2.0 Expo, Brad Neuberg (the developer) gave a presentation on the Offline Toolkit; watch is his presentation for more details.

Having the capability to build web applications that are “connectivity” aware is a big boost to the acceptance of web applications. Ubiquitous connectivity is still a dream. The thing is that the way Web applications are designed and developed changes as a result. The MVC structure of your typical Web application now needs to push the entire MVC structure into the Javascript. Rock on PAC! Dojo is well suited for this architecture as it includes many features for neatly structuring the Javascript application and deploying just what is needed and it can incorporate Comet.

No comments Digg this

Concurrency: You’ll have to understand it one day soon.

It is pretty clear that scale is an important topic these days. Scaling cheaply and reliably in a seamless fashion to boot. I noticed recently several talks/tutorials on scale and concurrency at OSCON 2007 and that Web2.0 Expo and ETech07 had their share too. There have also been numerous mentions of Live Journal’s and Myspace’s approach to scaling out recirculating recently. These approaches are considered the current blue-print for handling scale of web applications based on LAMP. I suspect mostly because it suggests you should forget about scaling and just let your architecture evolve along the lines prescribed i.e. Scale is a nice problem to have. And in a pragmatic-way I totally agree with that.

Returning forager The general approach at the application layer can be summed up as: Partition your database around some key object in the system, typically a user. Replicate these partitions around your various database servers. Deploy your front-end on a web-farm and potentially factor out some application functionality to dedicated servers. Manage sessions separately either by creating a discrete service within the architecture or by resolving sessions to a particular database partition – basically push state down to a data-store where the application coordination happens. Then cache whatever you can. That’s it – well the devil is in the details.

Don MacAskill’s presentation at ETech07 details SmugMug’s architecture using Amazon’s S3 and experiments with EC2 and SQS. It contains a great lot of information about using Amazon’s Web Services. The utility model – or compute power on demand – of deploying services will become very prevalent over the next few years. While Amazon are the first movers, others will follow with potentially more powerful computing models.

All good. Basically they are all large grained approaches to leveraging concurrent execution using lots of boxes. Application design is just chopped up into a few tiers. It is easy to understand and at this point we can happily forget about concurrency because each component in the system is a big black box with synchronous calls between them.

Several things are happening that suggest our sequential synchronous existence may be over. Power consumption, Multi-core cpu’s, on-demand scaling as exemplified by Amazon’s EC2 service, transaction reliability and the rise of data mining; All make confronting scaling issues early on important for your application architecture.

The situation for CPU design and the implications for software design was clearly discussed, back in 2005, in a Dr Dobbs article by Herb Sutter. The Free Lunch is Over: A Fundamental Turn Towards Concurrency in Software. In the article Herb discusses the limitations of chip design and why this will lead to a focus on multi core design rather than increasing clock cycles on a single core. A key barrier to increasing the clock speed is power consumption. Heat is a by product of power consumption so power consumption isn’t related just to the operation of a machine but the cooling required to keep it operating. Power consumption is a major issue for Google and any company that runs data centers. Even my little server room at home should have air conditioning during the summer months! Server power consumption is one of the motivations given as justification for O’Reilly Media’s conference on energy innovation later this year.

While two or four core cpu architectures are now mainstream we are seeing an increase in the number of cores. An example demostrated recently is Intel’s 80-core research chip crunches 1 Tflop at 3.2 GHz

“Intel’s 80-core chip is basically a mainframe-on-a-chip-literally,” said McGregor. “It’s the equivalent of 80 blade processors plugged into a high-speed backplane, or 80 separate computers using a high-speed hardware interconnect.”

I suspect that given Moore’s Law we can expect some associated Law regarding the number of cores on a square inch wafer increasing exponentially over the coming years. No doubt there will be some correlation to Peak Oil issues and increasing awareness of Global Warming as the market impetus for more cores. If approaches to concurrency in software are any indication, I can easily imagine clock speeds decreasing. Chip designers would focus on throughput rather than outright performance. This would suggest the rise of commercial asynchronous chip designs. [Maybe they are already – I know nothing about current chip designs beyond their multi-coreness.] It would also fit with Clayton Christensen’s “law of conservation of modularity“.

Current software development techniques can only hide so much. Eventually we will need to utilise the multiple cores to maximise the benefit they provide. Multi-threading is notoriously difficult to do correctly so I don’t see that as a solution. Asynchronous event or message passing approaches provide a better way. Basically they model how hardware works and micro-kernel operating systems have been modelled in a similar fashion.

We have being doing this application composition stuff with messages for a while now (albeit synchronous in nature) with Unix pipes and the Web but these architectures are only just beginning to be appreciated beyond administration script-based coordination Unix pipes have been traditionally used for.

Google have raised awareness and appreciation with publication on internal toolkits like MapReduce, Chubby and BigTable.

One thing that surprises me about various presentations around scaling web applications is the lack of mention about message passing, specifically message queues or event buses. These are the staple tools when you want to scale and ensure data doesn’t get lost. Then again many of the consumer oriented services don’t need such reliability. The cost of losing a customers IM message, or comment post, or uploading of an image is minimal. An annoyance at worst. As web applications evolve into business applications losing data, due to scale demands, has real costs.

No comments Digg this

The next thing after 2.0!

It seems technology suffers from fashion as much as the fashion industry in that we must keep moving on to the next big thing before we have even understood the current thing. Regardless, despite disliking the term and being too lazy to even attempt defining a new one, recently I took the bait over at ReadWriteWeb to provide a definition for Web3.0; It seems they liked my definition of Web3.0. Here is what I wrote:

Web 1.0 – Centralised Them.
Web 2.0 – Distributed Us.
Web 3.0 – Decentralised Me

Hindsight: Web 1.0 turned into a broadcast medium. It was all about them. A case of industrial age thinking applied to a new landscape. Web 2.0, largely based on an analysis of what worked in Web1.0, is an alignment with TBL’s initial vision of the Web. The Web as connective tissue between us. Platform, participation and conversation. Really it is more than the Web. It is the Internet. It is new practices too. Ultimately it is about connectivity; applying constrains in the form of some sort-of agreed upon standards that make it easier to talk to one another. With new layers of connective wealth come new tools. In Web2.0’s case that allowed new forms of communication. With it associated ‘acceptable’ business models – hence the Google economy.

Web 1.0 was the first time to show the value of standards, Web 2.0 is teaching us how liberating standards can be. Web 3.0 will reflect on what worked in Web2.0. It will mean more constraints for better communication/connectivity. Improved connectivity will mean revised practice and new business models.

Therefore Web 3.0 must be about me! It’s about me when I don’t want to participate in the world. It’s about me when I want to have more control of my environment particularly who I let in. When my attention is stretched who/what do I pay attention to and who do I let pay attention to me. It is more effective communication for me!

When it is about me it means Web 3.0 must be about more semantics in information, but not just anything. Better communication comes from constraints in the vocabularies we use. Micro formats will lead here helping us to understand RDF and the Semantic Web. With more concern over my attention comes a need to manage the flow of information. This is about pushing and pulling information into a flow that accounts for time and context. Market based reputation models applied to information flows become important. Quality of Service (QOS) at the application and economic layer where agents monitor, discover, filter and direct flows on information for me to the devices and front-ends that I use. The very notion of application [Application is a very stand-alone PC world-view. Forget the Web, Desktop, Offline/Online arguments] disappears into a notion of components linked by information flows. Atom, the Atom API and semantics, particularly Micro formats initially, are the constraints that will make this happen. Atom features not because of technical merit but by virtue of it’s existing market deployment in a space that most EAI players won’t even consider a market opportunity. Hence Web based components start using Atom API as the dominate Web API – Feed remixing is indicative. Atom will supplant WS* SOA.

User centric identity takes hold. This extends the idea that everyone has an email address and mobile number, why not manage it for single sign-on and more. Universal Address-book anyone?

More Market based brokerage business models emerge, earning revenue on the ‘turn’, as we learn more about the true power of AdSense/Adword’s underling business model and realise there are close parallels to the worlds financial markets.

Reliable vocabularies, user identity and trusted [i.e. user controllable] reputation models, market based brokerage business models all become a necessity as the more decentralized event driven web becomes a reality.

Web 3.0 – a decentralized asynchronous me.

There were a few things I forgot to put into the above definition and from the comments a few things that need explanation. I’ll attempt to expand on the above in latter posts as I’m a little stuck for time.

What I left off is the relationship to the physical world; “the Internet of Things” with 2D Bar Codes, RFID etc. and Just-in-time just-about-one-to-one manufacturing that is partly represented by what Threadless and others are doing. I’ll also need to clarify what I mean by Them, Us, Me. And why Web 3.0 cannot be classified as “Read / Write / Execute.”

Some comments past on to me ask how is this different from what Web2.0 is about? At a technology level it really isn’t, the technology is already here. From a cultural and hence practice level it is. As we starting seeing more value in using things like Atom, Meta-Data, Open-Data and feed remixing etc, then how we use the Internet and our connected devices will change. That is what, at the core, is the basis of Web2.0 – changing usage and practice.

2 comments Digg this

Is Erlang the language of choice

Commenting on the recent (early) announcement of the new Pragmatics book on Programming Erlang, Tim asks if Erlang will be “language of choice for concurrent programming.” I’ve had this discussion with people over the few years that I have been dabbling in Erlang.

Firstly there is a question of Erlang adoption, regardless of Erlang’s suitability for concurrent programming. Two barriers stand in the way of Erlang adoption for many people, Erlang two strengths:concurrency and functional language.

Functional Programming is not culturally accept or understood very widely. Still considered as more academic. Real effort is required to learn a new programming paradigm so you do it out of interest. It is great that languages like Ruby, Python, XSLT and a rise in the love for Javascript (Javascript is a Functional Programming Language at it’s core), all help raise the level of understanding for expressive power in languages. These languages all make functional primitives available which is good. However unless you have read Abelson or similar, done a course in functional languages the concepts, when directly confronted with them, are just to foreign to get to grips with. We don’t think functionally even though it is not that different from an Object Oriented perspective. Maybe that illustrates my point; most OO languages are used in a object based fashion. It is just so hard to shake our procedural world view.

I’m sure there is a relationship between this and the markets acceptance of Lotus Improv (now Quantrix – think OLAP spreadsheet and is really good for financial modelling); in Excel you could be ad-hoc and evolve what you did, Improv forced you to think first. Which reminds me that millions of people program in a functional manner, they just don’t know it. Anyway it doesn’t help that a lot of writing about functional programming concepts are just explained badly.

The second difficulty with Erlang is concurrency. Again the concepts behind concurrent asynchronous message passing software development are just unnatural. We solve and think of problems synchronously. Weird since we live and operate in an asynchronous world. The odd thing is that in Object Oriented systems “messages” are passed between objects. Component development is not that different either. In Erlang Processes are objects and messages are passed between them.

Aside from the above I can’t really comment on Erlang being the language of choice for concurrent systems. For me it is, therefore I’ll just spread the word. Take a look. A clean simple language with a supporting framework for building robust systems. Joe’s latest book, that I purchased immediately, will be a great contribution to the language and no doubt will introduce many more people to the language too.

Update: Seems Ralph Johnson thinks Erlang is Object Oriented too. In a recent post “Erlang, the next Java” he expresses a similar view: that Erlang is an Object Oriented Language…Therefore the Erlang Community (Joe Armstrong in particular) needs to down play the importance of the Functional Language aspects and instead focus on the Message passing between processes (i.e. Processes are just objects that receive and send messages).

1 comment Digg this

Next Page »