Binary Object REst Distributed (BORED) system - Part 1

I was recently involved in a long discussion over at Steve Vinoski's blog regarding RPC and REST. The discussion was been long and multi-faceted covering definitions of RPC, REST and various other aspects of distributed computing. Steve has recently closed the loop on the discussions referencing some comments from Stu Charlton which offer a higher level perspective. The whole thing is a good read if you're into learning about the innards of the web and views on distributed systems.

One of the benefits of having these types of discussions is learning new perspectives and technology. There's nothing like getting into the nitty gritty and working out where opinions and ideas intersect. One of the things I learnt along the way is that I had misunderstood the meaning of REST. I was told to go and read Roy Fielding's (the person who coined REST) PHD dissertation. Unless you've read Fielding's dissertation it's most likely that you don't actually know the true meaning of REST. To quote myself in Steve's blog after I had read Fielding's dissertation:

"REST is fundamentally not RPC. REST is an 'architectural style' that is designed to ensure that the web's hypermedia solution to distributed computing will not be ruined by future changes. REST is not a design pattern or an implementation. You could look at the actions of REST and loosely suggest as I've done in the past, and Michi has, that they have some similarities to RPC. I don't think it is an argument worth pursuing. This does not mean that the REST architecture doesn't look like RPC on the client, but I'll get to that later. REST is as different from RPC as it is from Message Queueing or Publish Subscribe systems."

Of course Wikipedia has a better description of the situation:

“REST strictly refers to a collection of network architecture principles which outline how resources are defined and addressed. The term is often used in a looser sense to describe any simple interface which transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict as well as overlap”

I've been asking myself, how can I apply REST constraints to a binary protocol? I've spent the last week or two developing a thought experiment for a protocol design for a Binary Object REst Distributed (BORED) system. This may not go any further than a thought experiment, however, it should highlight some of the trade-offs you make when developing a protocol. With some luck I'll attract some other smart people to throw in their thoughts and may end up with something useful; or at least some useful material for future work.

Future posts will go into the detail of the BORED protocol; however, for now I'll highlight the guiding principles:

• REST - REST has a strong architectural style that has many benefits for internet scale distributed systems. This has obviously been proven by the World Wide Web. The BORED protocol must live up to the architectural requirements specified by REST.
  
• Binary - The data encoding will be binary. I have a long history with binary encoding with Argot. The protocol will leverage the learning and methods used in Argot. The protocol may still be applicable to other binary encodings.
  
• Object - Integrating the REST model with an Object model is to a certain extent a direct contradiction. However, there's a huge disconnect currently between REST and programming languages; I'll see if I can find a way to align the two.
  
• Scalable - The solution must be able to scale from tiny embedded devices to enterprise systems. Embedded devices require a protocol that can be scaled to respond to requests in only a few KB of code.
  

The above should provide the flavour of the protocol to be designed. Obviously, there will be trade-offs.

Also, I should mention, the name BORED was probably not the best acronym I could come up with. I think it's somewhat fitting though, as I'm bored with all the arguments about which distributed system is better. I'd rather work on how to combine great technology to make even better systems.