1. Hi Subbu, would you like to introduce yourself?
My name is Subbu and I work for Yahoo! I have two day jobs: one primarily focusing on serving large volumes of user data, like I manage platforms that serve user profiles content like user generated content, location, identity and things like that. My second responsibility is actually to understand and find ways to make our platforms interoperable.
I think that's a good question and a tough one to answer for two reasons: at detail level we tend to argue a lot of what the right things are or the right thing to do, whether a specific HTTP method should be used in certain ways, or whether a URI should look like that. I think that those arguments have sort of subsided in the last couple of years. We used to argue a lot more before that. But I think at the macro level the problems are getting the quality attributes of systems right and most of us, when we learn about REST, we start with the constraints and not from what attributes of quality led to those constraints. I find it very useful to do that and I really encourage starting from quality attributes and arrive at the constraints and that helps a lot.
The second mistake or thing that we need to pay attention to is getting things to work together. I think that we're at the point where interoperability is going to be a challenge. If we have a number of HTTP-based applications built by different teams distributed globally, getting them to agree on certain things is really important for interoperability. And that is going to be a challenge, as people understand REST better and better, there are going to be inconsistencies and we need to be able to understand.
3. You talked about quality attributes. Would you like to elaborate a little bit on that?
What we call quality attributes and these are the things that you expect your system to satisfy, so that it can meet certain user scenarios. For instance, in case of a failure of a certain kind, how should your system react to it? That is a quality attribute and you need to design for that, it doesn't happen automatically. REST doesn't guarantee that, you have to think about it and bring systems that do that.
I think the biggest is interoperability and you get 70-80% of benefits out of caching itself. If you don't understand or get the rest of HTTP or Hypertext or so on right, you still get 80% of your benefits out of just caching itself on a large scale. To me, that's a clear winner. An interesting thing that I'm beginning to realize is this notion of serendipities to use. This is a word that I think 4 years back Steve Vinoski talked about, I think at this very conference. I didn't clearly get it when he mentioned how it can happen, but having been on the ground, doing REST and HTTP, I see that happening every day and that is the biggest benefit. We haven't seen such a technology equaling that prior to the web as a platform.
Given the work that was done by folks like Sam Ruby and Richardson's excellent book on REST and the talks that were done by Ian Robison and Jim Webber, my own book on REST, I think the debates have sort of subsided to a large extent. I think that the only thing that we're all trying to make sense of is Hypertext constraint. Beyond that I don't see a lot of debates happening these days.
I think this is an excellent question. In my mind, REST as an architecture is designed for decentralized fairly decoupled systems. When you bring in things like transactions, you are actually talking about some sort of coupling and dependencies between those two decoupled applications. When you are making writes on two systems that you probably don't control yourself, getting them to commit some data and maintain consistency and other quality attributes is a hard thing to do. I think there is an inherent conflict in trying to approach things like transactions and the web as architecture.
You don't do transactions on the web the way you do transactions in a controlled environment where you can agree or you can expect the agreement. Here you can't expect the agreement and that is an interesting aspect of the web as a whole, as a platform, that you agree on little things these protocols might not agree on everything. That's the point of a decentralized web.
Even though the protocols that we use for the web like HTTP and URIs are old, not modern, on the internet age, we are still getting a lot of stuff out of those protocols because they were designed with the right abstraction and they were designed with the right quality attributes in mind. Given that, I don't actually see there is a limitation. In fact, we have benefited a lot from these technologies. The pioneers, like Tim Berners-Lee and folks like that have worked for the mankind, so we were able to get things out of it even today.
Of course, there are limitations, there are inconsistencies, interoperability issues, from the HTTP stack, HTML and so on. Progress is hard in these areas because these are protocols and in fact they need to be done over time so that you can get it right. Personally I'm happy with the progress. I think the right minds are working all the time, thinking about the basic issues of the web today.
This is the most commonly used recipes as far as I know from the folks I talked to, are finding resources. I think one of the things I tried to emphasize a lot is that anything that your client application needs better resource and secondly the recipes on getting concurrency control, like doing different kinds of writes people who come from SOA background ask questions on transactions and then I see them in action these days.
9. Are there any patterns you feel that are not very well known and should be more widely used?
I go back to the concurrency control and there is the biggest area that I think developers need to pay more attention to and I tend to emphasize that a lot. Of course, caching is a thing that people need to get and design for it. Often times developers don't design for things like sending the right response headers like last modified, getting ETags right, and so on.
I go back to the quality attributes: if your quality attributes are such that the benefit of the web is not your goal and if you have to tunnel reads and writes, so be it, but you probably are aware of what the consequences are. I think the key point is that you'd better be aware of what tradeoffs you are making. If it is time to market, for that reason for making a tradeoff, it's fine.
I would say for getting HTTP-based applications there are so many tools in any language. I can write in JavaScript to Ruby, to PHP and Python. There is a stack for everything. The tools for those languages are as mature as languages like Java or C#, etc. but it is something that the community will drive, the market will drive. So to me, there are a number of tools I can use app and give tools on my desktop, like curl and wget, and web server like lighttpd and Apache – those are my tool stack.
I see two main changes in the way the protocol is evolving from what it was before: the first thing is the key. As a protocol it's simpler, it decouples the way access tokens are granted to clients and how they are communicated to servers so that it can make the protocol extensible, you can find new ways to tokens. It tries to unify other forms of authentication like SAML, so it is extensible. That is a very important characteristic of the protocol. The second is that by not enforcing signatures now, I'm not sure what's going to happen to the spec in future, but now to me it seems like a good thing and I know that there are concerns on both sides.
But I think in the interest of interoperability, by not having signatures and using access tokens like using cookies makes it easy for clients. Hopefully, by getting TLS right on the client applications you can avoid using signatures but still get the same amount of trust on the wire.
This is a very interesting point because I come from a company that one of the things we use to often ask when we shipped a product was "What can the customer do in the next 30 minutes or a given amount of time? Can he get something meaningful out of it?" I brought it up recently because it is a tendency that when developers think of their platforms, their web services, their applications, they think they are special. Everyone thinks his application is something different, something special, more useful and peculiar in certain ways. In reality, if you look from the client's point of view, all the client is interested in is getting his stuff done; he doesn't want to take each application as different from others.
To me that's an important quality attribute because from the client's point of view they need to be less special and not more special, even if you are doing a complex thing. Even using Google Maps, or the Yahoo! Mail you want to use it like any other website. They are the same for the end-user. The same applies for web services, the same applies for any large system.