 Before I get into the meat of the talk, though, I'd first like to just thank Francis and all the great Garouko folks. This is quite a conference, a lot of fun so far. Give him a big round of applause. I'd also like to thank you folks for coming out and supporting the Ruby community and conferences like this that I think are a big part of what make the community special. I came out here from LA, but I grew up in Detroit, so I have no problem saying I love New York City and it's been too long since I've been here, so it's a great opportunity to come out and meet a lot of new folks. A little bit just to introduce myself a little bit. In the program, it says that I'm from AT&T Interactive as of about three days ago. That's no longer true. I've moved to a startup in Santa Monica called sharespost.com. If you've ever thought to yourself, man, I'd like to get in on buying some Facebook stock or Twitter stock. That's what we're trying to make possible private equity trading. I'm also the lead developer for WAVES and in the role that I had at AT&T, I was doing a lot more managing, so my GitHub account shows a little bit of a lull and commits over the last few months. I'm hoping to kind of get back and be a little bit more hands-on. But I still am allegedly the lead developer for WAVES. There's some of my contact info there and part of the fun for me of doing these talks is meeting all of you folks. So I genuinely hope that you will, if there's anything in here at all that's interesting or that you think you might at some point want to talk more about or you have ideas that you think might influence the direction that we're trying to go with this project. I really do hope that you'll reach out and get in touch and we can get to know each other. Google, a couple of days ago at Google I.O., announced a project called Google WAVE. So I'm either now faced with changing the name or answering the question about what this has to do with Google, which is nothing, at least not with that project, nothing directly. Also, thanks to a certain incident I've had to do away with the Surfer Babe, which was at the end of each one of my presentations. I won't say any more on that. So first I want to pimp WAVES a little bit. I think I've made the mistake in the past on these of not really talking enough about what WAVES really can do today already. I mean, it is under development, but it's in use on production systems. It's a fairly sophisticated framework already. I tend to like to talk more about the things that we're going to try to do in the future than what it already does, but I don't want to sell the framework short, so I'm going to talk real quickly about a couple of things about WAVES just to kind of give you an idea about what it already does. So there seems to be a couple of different themes in terms of Ruby development. Initially, it was all about MVC and Rails. That was the big sort of initially it was before Rails, it was about a lot of other things, but the really big kind of Ruby blowing up and coming of age was the emergence of a viable MVC framework. Then we sort of started getting into an area where people started saying, you know, I don't always need a full-fledged MVC framework. So I want to do something real simple. A lot of people have used Sinatra for that. I just want to make the case that you can come pretty close to the kind of compactness that you get with Sinatra, but just by using WAVES. And what you see here is an example of the power of one of WAVES core features, which is, and this just illustrates one aspect of it, hopefully the code is big enough to read, probably maybe not, but it has basically, it has a nice DSL for accessing and mapping to HTTP requests that you can sort of use in a lot of different contexts. So it's a little different than conventional MVC style routing that you see with, say, Rails. And so I can match on a lot of things the accept header, the query, and I can do it, you know, as not, it's not a unnatural thing to do. So in this case, you see I'm matching, I'm saying, look, there must be a query parameter in the request called name. There are a number of those kinds of primitives. In this case, we're using the Compact Foundation, which allows me to build a very, very sort of small compact kind of Sinatra-like app. But if I get new requirements, you know, I can also go to handle more sophisticated things. This is a more traditional web app that uses what's called the MVC Foundation. So these foundations are sort of pluggable into WAVES and give WAVES different kind of character, depending on what your requirements are. The nice thing about that is you can start simple and then as your application evolves, you can bring in whatever foundation makes sense or additional, what we call layers. So a foundation is made up of layers. You can build your own foundation. So this is an example, one of the, I think both Gregory and Eleanor mentioned, Rubinius. So one of the Rubinius developers has been working on a DSL for building more restful web apps and was able to add that in as a foundation. So this is an experimental foundation that's been being worked on by Eros and Akari. Another one, this is a little bit more for services. This is one that I had proposed, we haven't implemented this one. But these are the kinds of things, and then this is more about what I'm, so this transitions into kind of going forward. So here you see an attempt to sort of represent an actual resource server with the DSL that directly expresses the abstractions around rest computing and resource oriented. Some other things, so again WAVES is pretty full-featured. It has things like inheritable configurations that Rails still does not have. I actually thought about pulling that out and some of the other features into a gem. There are really nice kind of decoupled implementations for workers and dispatchers, so you can really, you know, really do quite a bit in terms of customizing and creating your own sort of flavor of web server. Some of the other features there, I won't go through them all, except to mention one in particular, I think it was Gregory had mentioned how great JRuby is. We've had the same experience. And the nice thing with JRuby is from a scalability standpoint, it's very simple to deploy, right? Because you don't really have to figure out how many, I think Eleanor mentioned, you know, letting somebody else do the work of figuring out how to leverage a multi-core architecture. And JVM sort of have that characteristic, right? There's somebody that's spent probably a whole team of people on any given architecture that have spent a lot of time making sure that a given JVM is optimized for a given systems architecture. And you can leverage that. You just run one JVM and you can basically scale up to the limit of the machine. And there's nothing, there's nothing more to do. And we've been doing that not on huge load, but actual production stuff just has never gone down. We've been running that for months on, you know, hundreds of thousands of requests. Now, one of the things that I get a lot after I go through some of the more arcane, interesting things that we're trying to accomplish with waves is people saying, you know, that's fascinating, but it doesn't really impact me at all. Everything I'm doing really fits perfectly well within the MVC paradigm. And that's probably true for most of you. And I, you know, I'm not trying to make your life more complicated. But what this really is is a symptom of the fact that the, by far the most successful web client is the browser. But that's not necessarily going to be the case for the indefinite future. We've already sort of seen people start to do things within the browser where they're effectively tunneling with things like Ajax and Comet, right? And, you know, we're really starting to do more and more stuff where you start to worry about, hey, I should set the accept header in the request. Or, you know, I don't want to rely on the browser's built-in content negotiation in some fashion. And with the emergence, I think the last time I checked on Programmable Web a few months back, there was well over 1,000 publicly available APIs. That's going to continue to grow. I think more and more of our applications are going to be putting together multiple APIs, right? So, mobile is a big inflection point where we see these sort of hybrid clients where people want to build sort of native functionality, but they also want to leverage the fact that they have a server where they can update some features or update the business logic and so on and not have to release a new app. And I think that starts to go towards, you know, more and more where we're going to see people really using the web as a services infrastructure and not just something where, you know, you have a way to put an app in a browser. So, my favorite example of this is, how many of you are familiar with an open source project called Boxe? So, we already see the IPTV coming to us, right? The Apple TV sort of has one. It's only a matter of time before, by the way, I'd love to see a Ruby Boxe. I don't know if anybody's working on something like that, but if you are, please let me know. But once you get there, you know, you start to realize, hey, you know, the potential for interactive TV for, let's say, you're watching a news program, right? And there's something that you do, some country or person that you want to know more about but, you know, the natural language is being parsed as it comes through and things are popping up on the bottom of the screen. On the name, it brings up some information or data about that particular thing. How many of you have been following the World From Alpha launch? So, there's another example, right, where this guy has built a search engine that sort of semantically parses web content and allows, makes it possible to do some analysis. So, I think we're moving more and more towards a very, very different kind of web and so if it hasn't impacted you yet, you know, it's something to kind of keep your eye on that, you know, the MVC view of the world and the browser-centric view of the world isn't going to be with us forever. And one of the profound things about this is HTTP itself is actually not MVC and I'll talk about what it is here in a minute, but one of the things I want to get across and this kind of goes to the theme of using not just Ruby but really the web itself to its full potential. You've heard the, I don't know, there's some statistic that we only use like 3% of our brains or something and we really only use about 3% of the power of the web and the idea is that Waves is there to help you as our collective requirements evolve past MVC, Waves is there to sort of help us figure out how to, you know, how to write frameworks and build applications that take advantage of that. So again, you saw earlier, I talked about the foundations and layers. Waves just is much more flexible than traditional frameworks. It allows you to mix in the features that you want and then build from there. So you can start very simply and then go on. Now, I want to talk a little bit about the terminology I'm using. REST is a very controversial term, right? And if anybody's followed Roy Fielding's blog, you know that he's very irritable. And one of the things that he gets kind of, I think, reasonably upset about is he invented the term REST and then finds himself in arguments with people about what it means. So you can imagine, it reminds me of, if any of you are old enough to remember use cases and when they first started and a guy named Ivar Jacobson invented the concept and then, you know, there was this endless debate about what use cases were even though he'd written a book on it and it was all pretty much defined clearly in the book. REST is sort of like that where I think if we want to move beyond talking about REST, an appropriate term is a resource-oriented architecture. So if you want to freelance a little bit and you want to get outside of what's strictly speaking, you know, Roy's definition of REST, then I like to use the term resource-oriented for that. And resource-oriented, unlike REST, isn't just a set of constraints. We can actually talk about a real architecture and try to pin down, okay, it's HTTP-based, it's, you know, it's got these conventions, uses these standards and so on, which, like for example REST, it doesn't talk really specifically about HTTP at all. So what I'm really trying to talk about from here on out is HTTP-based resource-oriented architecture. The great thing with the web is that we've already got a huge proven infrastructure in place, right? So we don't, it kind of amuses me, I had a recent discussion with a colleague who was talking about wanting to implement a custom protocol for something. And as soon as you do that, right, you kind of throw away the advantages of load balancers and firewalls and all these things that are already sort of there to help you scale something, help you manage it, managing and monitoring, you know, any kind of HTTP-based services already sort of built in. And HTTP itself is a pretty sophisticated protocol. So, but the funny thing is there's been a lot of the confusion has been around the different verbs and how to use them. I think the best way, and I think this is based on a fair amount of study of what, you know, looking at the REST distortion and reading between the lines of Roy's blog, which is a little obfuscated, I think. But when you really kind of get down to it, what you're talking about is a distributed hash table, which is an incredibly powerful abstraction. So if you take, you know, things like memcached or shared memory, right, I mean, what we're really talking about is key value pairs. So it's a very, very flexible way to do a lot of different things from, you know, messaging to caching to whatever. And this is what HTTP is providing us, a distributed hash table. And that makes a lot more sense of the verbs, because now you can sort of see the construction, right, get and put and delete. And you can use, you know, head to sort of check to see if a value is there. Well, Dan, you know, what about post? Well, post is sort of everything else. Post is the fallback. And it's not at the same sort of level. It's not of the same level of primacy. The other verbs, for example, are idempotent. Post is not. And the reason for that is because we know the semantics of the other verbs that are defined much more clearly. Post is saying, look, not everything fits cleanly in the constructs of a distributed hash. So I'm going to define a different verb that allows you to sort of do whatever else you want that, you know, might not fit efficiently in a distributed hash abstraction. So what goes in the hash are these things called resources. And we put things in and out using representations. I'm going to talk a little bit more about the split here. The keys are the URIs. And we put representations in and out. But we're really putting resources in and out of this big hash. So what's a resource? Well, it's really kind of, if you think back to your object-oriented programming days, what we're really talking about is objects, except that in objects, usually we're talking about within a single programming language, right? So we don't worry too much about the difference between the representation of an object and the actual object itself. In the cloud, however, we are assuming a very, very heterogeneous environment where the odds are, in fact, that the client and server are going to be different platforms. So what we want is a platform-neutral way to approach this problem. And I think on top of that, you know, objects are sort of, the term is overloaded. So the nice thing is saying, look, let's just forget about all the history here, but remember the construct. We want some kind of thing of saying, this is an entity, a thing, a noun. And now, so I've got my resource. And then in order to support a number of platforms, I've got my representations of that resource. So I'm taking the concept of an object, splitting it into two pieces. Again, going back a little bit, if you're old enough to remember, this is like the holy grail of computing. This is a big deal. There's been many, many attempts to solve this problem. And HTTP, sort of while we were sleeping, has actually solved the problem quite elegantly. But I think resource-oriented goes a little bit beyond even that. How many of you are familiar with a resource description framework, RDF? I think it's something that's worth getting familiar with. And the reason is that it's sort of a crucial, you need something like RDF. If you're familiar with service-oriented architecture, you've probably seen Wisdolls and XML schemas and so on. Well, RDF is kind of the restful answer to those things. It's much more flexible. It sort of unifies both the schema side of it and the resource description side of it into a single framework that's quite extensible. You should check out Freebase to get a freebase.com, I believe it is, to get sort of an initial idea of the kind of power of RDF. And what RDF allows you to do is sort of provide a generic standard entry point into a set of resources so that you don't have a whole lot of things where a programmer has to sit down and read your documentation to figure out how to call your services. And what we're really trying to do is the same thing that I think Ruby has done quite elegantly itself as a language, right? Which is principle of least surprise and that sort of begets all kinds of benefits. If you get a nice, elegant architecture underneath the covers, you know, you start finding that you could do things that you didn't realize you could do. You can combine things that, you know, you hadn't thought of combining when you first designed a system. And so going beyond the original conception or design of a system, that's sort of the essence of mashups as well and that's what cloud computing I think is really going to be all about. So being able to have a sort of machine-readable and discoverable and dynamically composable set of services is actually the key to, you know, getting this kind of fusion reaction inside of the cloud. I just made that metaphor up off the top of my head. A great case study of this is RSS and Atom where I don't really need to know the specific link structure of your blog. I don't care whether you made your URLs readable or if they're MD5 hashes. I don't care because I have, in effect, sort of an RDF file. It's a little bit, it's sort of a derivative of RDF that describes the structure of your blog. And in fact, because it also provides for content negotiation, we got the unintended consequence of podcasts came out of that where I could describe other media types besides just an HTML web page. And I can get all of this with a single link. And that's the kind of the key thing we're looking for is I can write generic clients. I can give you an RDF for a given service or services and you can take it from there because that's the only dependency that I have. And that's kind of the essence of loose coupling. And so we've already seen it in action. And if you kind of ever get like, okay, wait, why am I doing this again as you're playing around with these things? This is what we're trying to get to. Now, I'm going to sort of, yeah. Oh, sorry. I thought somebody was raising their hand. I'm going to kind of go through just some different practical examples of wins in HTTP that I think are interesting and that we're trying to make easier to take advantage of in waves. One of them is the notion of edge caching. HTTP has an incredibly brilliant way of handling caching. Well, it's actually kind of more the definition of caching in a sense. What we think of in particularly, I think in the MVC world, we think of caching in terms of offloading things from the database. But from a scalability standpoint, what you really want is to offload it from your server entirely. And the caching policies that HTTP already provides, which allows the actual client to cache things. So it doesn't even go across the network at all. A request is never made because I know this data is in all likelihood still good. In a lot of ways, a much, much bigger win than using something like M-M-Cached. In waves, for example, you could use Rack Cache or you could just do this with Rack as well. But you can write a simple wave server, put it out in front of your different application servers to handle caching and offload it from your servers entirely. But you don't really even need that because a lot of intermediaries along the way, no matter how many hops it takes, I mean it can either get cached at the client or if I as a client have never seen this data before, it may be one of the intermediate hops that I'm looking at will have seen it. So if you ever have used CDNs or anything like that, this is the same concept. But we can apply this to our applications. We don't really necessarily need to have CDNs and or just M-M-Cache. I mean you can do this yourself. Another example is making the network itself smarter or another example I guess of making the network smarter is refactoring things that are complex or error prone like security protocols out into a firewall type of node so that anything that you want can now actually use the same implementation. So you get one implementation of something like OpenID, you get it right, and now you just can use that across all of your servers instead of trying to embed it within each single server. And again, Waves allows you to do things like you don't really need a URI, it's not a URI centric, the HTTP request handling is not URI centric. So you don't even need to define a URI, I can say look, on any request that's a post, put or delete, I want to make sure that it's an authenticated request and now I've just picked that up for my entire, no matter how many nodes I might have, no matter how many different applications I might be running, I now know that there's no way requests are getting through that aren't authenticated. Now you can of course do that in many firewalls, you can do things like that as well, but sometimes it's nice to be able to use the same kind of application logic where I just want to write a Ruby OpenID server or client really to check authentication, right? So I do that and I don't have to worry about that on each one of my applications and I don't have to go into a configuration that's not in Ruby in order to do it. Another kind of interesting best practice is that a lot of times people using the term RESTful kind of violate this rather badly is instead of, in this example, I've got a link as the value for updates and fans. So I've got this sort of Twitter clone, instead of followers, I've got fans and... So, you know, now the URLs there are sort of semantically meaningful, but they could be anything. The point is again that the client doesn't have to know them in advance because they're embedded in the data. It's like a reference in the data. And what you'll see though with a lot of APIs is they won't even have those attributes at all. Instead what they'll have is a web page that says, okay, now if you happen to need to get the fans of a user or followers or whatever, call this URL. And that starts to increase the coupling between the client and the server. I now have more things that the client has to sort of know about in advance. If I just put the links inside the data that I'm returning, then I have this sort of nice property that I can change that URL to anything and the client will still work properly. Another thing that you sort of see a lot is people putting the format specifier in the URL. Again, this is a bad practice just because what I'm trying to do is describe a key for a resource. I don't want to specify the representation as well. And when you look at linked data, you can kind of see the value of this, right? Because I don't know, you know, what if the client decides, hey, I want to get the followers as a web page and I want to get it as JSON or I want to retrieve it as XML. I mean, it should be up to the client to be able to say I want to dereference this link and I want to get this representation. What's more is that the extensions don't really fully describe what we're asking for. If I start dealing with multiple languages, now I have to have that embedded into the URL somehow. And if I'm dealing with, God forbid, different character sets, I have to put that somehow in the URL. And all of these things increase the coupling in the server. I have more things that the client sort of has to, the programmer himself, a person has to know about. So I'm losing the properties of machine discoverability and dynamic composition by doing that. So it's rather simple and I put the curl statement up here just to kind of illustrate that it's really not that hard. I mean, you know, you have to get used to thinking a little differently. The team that I was working with at AT&T, we've gone through a definite learning curve on getting used to this and the resistance, especially for programmers that are really, really good at the MVC paradigm. It gets a little frustrating because they have to kind of unlearn some things. But once you start getting going with it, it actually starts to become quite natural because this all really makes sense. I have RDF for an entry point. I have my content negotiation to decide what representations I'm getting. And I have linked data to be able to navigate to find whatever it is that I want without having to know ahead of time what the URLs are. So, again, going back to the question of, well, what is Waves really trying to do? And I showed you earlier that listing where we were working on a couple of different REST DSLs, one for sort of resourceful web apps and one for resourceful services, because it turns out they have... We may be able to unify those later, but Iro and I have been in sort of in this back-and-forth argument about whether to make services more, to emphasize the services side of it or if we should have a really good way to do resourceful web apps first and then build the services off of that, I guess, is... And that's all happening, by the way, on the Google Groups. And, again, I'd love to have more people participating and giving their two cents on it to kind of get us to a point where we have some really useful DSLs in place, what we call foundations, again, in Waves. So, again, this is kind of a... It's a new paradigm, really, in a lot of ways that allows us to fully leverage the power of the web, which is really a distributed object, distributed computing architecture that's platform and protocol-neutral, really. It's extremely powerful, and we're only really using the... We've only kind of discovered the tip of the iceberg, I guess. So, please check out. We've got a new release. If you go to GitHub Waves, there's a stable in edge. So, edge right now is the basis for what's going to be the O9 release. We'd love to get people playing around with that. You know, we'd love to have other people working on foundations or taking the foundations that we have and mucking about with them and that sort of thing. So, again, there's my contact info. Are there any questions that people have? I'd be happy to take a few questions. So, you had said that the URL or the pressing URL itself shouldn't specify the format of the resource. So, in your example, like .xml is too specific to move that into the accept header. But, I guess in your example, let's say if I wanted to request shoe number one from some website and said to shoe slash one .xml, and then let's say I want to see in Japanese, like where would you move that other I guess requested format in your exact language? Right, yeah, exactly. Dan, I'm following that which is that. The header stuff is pretty awesome in theory, but unfortunately not all the parts of the stack have implemented yet. We've had a problem at sling, actually, where we try to get calls that you post their gets. And they do accept js. There's no .js, or JSON, or I forget what it was, or whatever, but it's overwritten with it also to return html. Oftentimes it doesn't track these. So, we'll get these things where someone will first hit do this get on this URL with an accept and we'll return html. And then the second way that someone will do a second get on the exact same, the URL is the same, but the accept is the header is different. Altima doesn't care. It just thinks it's giving you html. So, we've actually had to, we last restful, unfortunately, and that's an area that we should just not use up on, obviously. So, I guess the point of raising is that I think all this stuff is really awesome, but I think also html is a set of conventions that the entire stack is working on, where how well they implement everything is a varying quality. So, we've had similar problems. In fact, the browsers themselves will just blatantly overwrite the accept headers with things sometimes for, you know, like if you have a .jpeg on a URL and it'll just say, okay, I'll accept some of the browsers and just do star dot star. You know, I'll take anything. There's definitely some gotchas. It's like any kind of new paradigm. You have to kind of work through the issues. And I think saying to people like Akamai, like, hey, this is a bug, man. I mean, we need either a version of this that works for more restful stuff or we're going to use somebody else. Yes. I suspect that they're trying to work around a bug or an implementation detail in Internet Explorer. Anything that has to do with Internet Explorer is going to have to have some special features. But without being distracted on that, I have a very fundamental question and maybe I'm just stupid or maybe I am and it's still my big question as well. But there's a lot of fuss about restful and what do I lose if I say, I'll forget about it. Forget about it. Who gives a shit? Sorry, that was the whole point of my talk, I guess. No, I think what you lose is the discoverability, the composability, the sort of unintended benefits that come out of synergies between all kinds of different things in the same way. You as an individual today probably don't lose a whole lot but if we all continue to go off and create our own little silos and I don't think that's where this is going. You look at things like OpenID and the social network APIs or Amazon's web services where I can now do monitoring and I can do auto scaling and stuff. Clearly this is all moving towards this big, vast collection of services in the cloud and I compose to do probably today maybe 10% of what we really want to do but it's going to increase over time so today you probably don't pay too much of a price. But I think over time that price will increase. Partly to follow on from that what you lose if you're not restful is you're fighting the physics of the net. You can describe rest as a distributed hash table but the other way to look at it is it's fundamentally the physics around networks that can lose nodes at any point in time. So you don't for a lot of application development it doesn't necessarily gain you anything now but if you can leverage it you make a lot of scalability issues just fundamentally disappear because they're part of the network structure then on your problem which is great. But related to that and it's all coming back to the linked data aspect a couple of years ago there's a bunch of DNS stuff and there's an area of DNS called Naptur resource records they are exactly that they are abstractions of URLs away from URLs their service all reacted and they're doing almost exactly the same thing you're doing there with RDF and they're right the way down they're in the network they're in the actual lookup of machines and I've banged on about this at conferences for a couple of years now I don't know about data publishing in DNS but all of this it's about moving us away from caring about the physical infrastructure and the DNS folks are trying to do it but they're finding it very difficult to publicise it last year Boyfield and gave a keynote about the computer that forward was clear from sort of like half way back was just clear before he was 20 minutes into what he was talking about and there were people outside he was like I don't see the point what's this got to do with web development well that's what the web is if you're a web developer and you don't get that you don't get the web so that's I'll talk to you about that separately it might be interesting stuff to actually try and fit into building that stuff into the DNS is actually a really interesting idea your scalability becomes phenomenal it is I think a symptom of the confusion around it I think is related a lot to we've been building browser apps but the web is potentially about a lot more than that so what does this have to do with Google again? starting already did you have any comments on the proposed HTTP patch method? no but I'd love to get your thoughts on it I haven't really looked at it I haven't I just kind of a random question but you know if we're talking about keys to resources and caching and browsers are really good at figuring out how to do caching but if you've got these keys in your restable app and your code do you have to also program all of the caching mechanisms into your code to decide when and where to update a new resource? yeah and in fact if you look at the oh yeah the question was you know how much logic do you have to put into your code to manage the caching to manage HTTP caching is that a fair and in the DSL the one that we're still kind of fiddling around with for services you'll see that in fact I'll just quickly put this up you'll see that there we go if you can read I don't know if you can actually read that but one of the core things when you're defining a resource is for given methods is when does that how long does that is that request request cacheable for when does that object expire yeah you do have to put that kind of thought into your app but the thing that we found that was sort of interesting is the more resources tend to be much more fine grained it's almost at the level of like when you do fragment caching if you have resources that are sort of fine grained you get to the point where you get things like fragment caching for free so it's if you've gotten to the point with your apps where you're doing like fragment caching and doing observers and all this kind of stuff then this is you know no different it's probably even a little simpler but yes you do have to put that into the application alright thank you very much