1. I’m here at GotoCon Aarhus with Stefan Tilkov. Stefan, can you introduce yourself?
Sure thing. Hi, Sadek, my name is Stefan Tilkov, as you said, I work with a company called Innoq and I like to say I spend half my time doing stuff nobody wants do to and the other half doing what I like to do, so I run part of the company in Germany and I actually spend the rest of my time working with customers on architectural issues, giving talks and annoying my colleagues with the actual work and actual projects.
2. And what have you been doing lately?
So in the past maybe two or three years I’ve been working on a bunch of web related projects so we have a lot of customers these days who start big web projects that have lots of integration issues but also face the typical challenges that you have in big web projects, like scalability and maintainability and so I’ve been spending a lot of time thinking about how to architect web based systems. And something I’ve been doing for a long time but more recently my focus has shifted a bit from what I did in the past which was mostly server to server communication more to classical web apps.
3. [...]What do you think of the state of REST integration into systems today?
Sadek's full question: Right. So, a few years ago when someone used to talk about REST, you’d get an army of people fighting against him because they don’t want to integrate this kind of services and now today it’s kind of reasonable to talk about REST, you won’t be scared to talk about REST, a lot of enterprises accepted, a lot of them implement some service like REST and now maybe we have to look at a new set of problems when implementing REST services. What do you think of the state of REST integration into systems today?
That’s a great question. So I can confirm, it may be selection bias, because I mostly get involved with people who have sort of an interest at least in RESTful design or RESTful architecture, but I tend to agree that it has changed a lot. It used to be the outsider, the minority view that you could do something with REST instead of using big web services and that has changed a lot these days, it’s almost always at least a viable alternative if not the given approach for people to start out and say “we’re going to build RESTful systems”. I think the state of the art these days is that fortunately, a lot of the debate is no longer being done, people don’t argue as much about it, they really have started to think about how to build systems in a good way, what are the, although I hate that word, best practices, what things have worked elsewhere, how can you apply those ideas to your own system. So these days I don’t spend much time educating people about what REST actually is, at least not the basics, it’s more having discussions how do you implement it efficiently, what are the finer points, one of the topics is hypermedia which always is still good for some discussion. But again, I think support for even that is improving in frameworks and libraries and people’s understanding is improving, the whole community is still learning how to apply it in different scenarios, so I think the state of the art has definitely improved over the past few years and we are now in a situation where we can actually exchange ideas and learn from each other and turn this into something that will really work well in our day to day work.
So I find out there are two things and they are sort of related. One thing is that people mistake RESTful design with URI design. URIs are a nice thing, I like pretty URIs as much as anybody else but they’ve got nothing to do with REST. So one of the things I keep saying over and over again in all those discussions is don’t worry about the characters that make up your URI, you can think of that later. But if anything on your architecture depends on certain combinations of characters in your URI, then you’ve done something wrong. You should essentially, that’s sort of a mental model, I think you should give your clients a single URI to start from and from there on they should discover everything dynamically, the client isn’t hardcoded against the characters in the URI, the client is coded against the relationship that URI appears in. That’s one of the major things and that’s of course the relation to hypermedia. So hypermedia is the least understood of the REST concepts, even though it’s a very obvious thing if you look at the way your web browser works, you’re using hypermedia all day, you’re using links and forms, which are also a way of doing hypermedia and you actually navigate from one state to another by means of following links or using hypermedia controls to actually turn the system from one state to the next, thus representational state transfer.
I think it’s not obvious when people start, they do certain things right, I think that’s a great start, to use GET and POST and PUT and DELETE for different things and you think about resources that make up the main concepts of your app and you often have links that connect, that’s at least something, still I think that people are often missing out on this more, I don’t know whether it’s an advanced concept, but on this lesser known concept of making things more dynamic by using hypermedia. You can compare it to the use of a registry in classical SOA, web services model, whereas in this classical SOA model you have somebody look a service up in the registry and then connect to it, which in my experience never really was done that way, but it was supposed to be done that way, in a RESTful system you actually have this sort of dynamics all the time, with every single request, you perform a request you get back a response and then in that response there will be certain things that include links and you can use them to interact with maybe the same server or a different server on a different machine in the same building or at the other corner of the world. You really don’t know, you don’t know what exact server you are talking to because you are discovering the resources to exchange representations with dynamically on the fly.
I think people know about it theoretically but don’t really see how to apply it, so I think that’s a matter of just showing people how to use it and in the next phase is that of course it comes at a cost, so hypermedia gives you more dynamic interactions but that additional level of interaction also comes with a cost, you can end up having more client server interactions so you have to adjust for the right level of hypermedia, you probably don’t want to have somebody have to go through ten different requests to arrive at some certain resource to interact with. So you have to use different approaches to do that. And then there’s an issue of documentation, so it’s very easy to document those URI APIs, that’s what they call those things where I give you a recipe on how to construct URIs, which is not RESTful, definitely not hypermedia, it’s the exact opposite. If you do that, then I sort of make you hardcode a lot of or make you bake in a lot of decisions that I would like to change later on, that’s when you have those things where you have to have a new version of an API because you changed the URI structure.
That’s something that should never happen, if you change the URI structure that should be purely a server side thing, which gives you an idea about the dynamics of the whole thing. Some people think that’s too expensive, I probably wouldn’t agree, but I kind of understand the reasoning when they say “yes, I want to have it very simple to document and I don’t care for that kind of level of dynamic interchange, I’m fine with having it hardcoded”. That’s ok, I probably would hesitate calling it REST, but then not everything has to be REST, if you know what you are doing, if you know what benefit you are not getting, I’m fine if you don’t use that approach. It’s just that I like to make people aware of the possibilities, so they can make an educated decision on whether or not to use that particular approach or not.
One example is the Facebook API, the new Graph API is in my opinion pretty hypermedia oriented, Netflix API is another example, a counter example is the Twitter API, most definitely not what I would recommend as a model for doing that. I’m not aware of many, I’m actually not aware of any publicly documented enterprise, internal interactions, we’ve done a few, but I’m not aware of anything that’s public that you can use as a model, which is a bit sad but that’s the way things are right now.
There’s very obvious thing, if people and I think many people have done that, if people have built their first resources using some framework like JAX-RS they have some support for using HTTP verbs correctly and they exposed those resources then typically you have a piece of documentation that says “these are the resources that we have and this is the way you construct the URIs”. And a very first step to hypermedia enable that is to create some sort of entry document, let’s not put that into documentation, let’s put that into a document. So, maybe for each kind of resource you have a link that says link rel=customers and then there’s the URI for the customer list and the same thing for all the entry points, in SOA speak, the entry resources that you want to have where you start navigating from. Then you have that collection of entry links, root resources, you turn that into a resource itself, and then you can imagine that a client will start up with just that one URI being passed to it by command line or maybe injected somehow and then it will retrieve that first document and use those URIs. That gives you an idea how easy it can be, it’s not a significant thing, it’s just one more request, the result of that request can be cached on the client for as long as the server says, in the appropriate control headers, and then the client just follows those links in there, so you can have the same piece of software use a different server or maybe a bunch of different servers because nobody says that all those links have to point to the same server, because the server doesn’t have to host all of the resources.
Sadek: Right. It’s interesting, the web started as resource oriented with hypermedia, in pages they have links, a very good example is Wikipedia where you start with something and then people go to other articles. At the API level we started being aware of this RESTful and resource oriented but the hypermedia is coming very late. But now it seems that at the client side we are getting back from hypermedia in a way, into single paged apps.
It’s a very good observation. So I think that’s a trend that I really don’t like at all. So I think most people have now learnt that we don’t need to have those big fat server side frameworks that have lots of session state and keep a component tree, all that stuff, we don’t necessarily have to have that because we can build lean stateless fast server side code, where you have an HTTP request that comes in and that’s handled using the database or whatever, backend interaction you do and then you send back a response, and the next request can hit another instance, doesn’t have to be the same one, no session affinity, that’s what we have learnt on the server side and it’s becoming kind of accepted that that’s the way to build modern scalable web apps, horizontally scalable web apps. But at the same time we’re kind of repeating the same mistakes we did on the server in the past but now we’re doing on the client side in JavaScript and that’s somehow good, which I find kind of weird.
So you could call that RESTful, for some value of RESTful, if you say that I have a server that exposes the RESTful HTTP API and I have a client, which could be a Swing application or an Eclipse RCP application or a JavaScript application that just uses that, but I think that is not something that is on the web, the same way that something that tunnels everything through HTTP POST is not on the web. So that’s actually a good, we’ve tried to come up with a bunch of guidelines, me and a bunch of other guys, actually a bunch of other guys and me, it’s really the correct way to phrase it, came up with a set of rules that we think make sense if you build a modern web app that is not a single page app and not a server side monstrosity. We call that ROCA, which is a fancy invention for resource oriented client architecture, there’s a website called roca-style.org, we’re not selling you a framework or anything, it’s just a bunch of guidelines that say this is the way that we believe web apps should be built.
9. Can you tell us a few of these guidelines?
Yes. So, obviously the very first thing is that we expect things to follow the REST model, so stateless interactions, you have resources, they support multiple verbs, possible have multiple different representations, and of course you use hypermedia, which on the web is really the obvious thing to do. So you could say that one of the central tenets is that in a web application that follows this ROCA style you really have pages and the page represents a certain concept, every URI means something. Again I’m not talking about the characters in the URI, I’m talking about the fact that if you look at something there’s a relationship between what’s in the address bar of your browser and what you’re looking at, this one thing, and if you move to another thing the URI changes, which rules out things like JSF, which keep the URI the same no matter what you do. This way we rule out something that does the same thing on the client, using the hashbang approach or something, where you just navigate exclusively through JavaScript, but the URI never changes, only changes after the hashbang sign, because that will not make the server represent the resource, that’s the first thing. The second thing is that we’re happy about the use of JavaScript as long as it’s done unobtrusively.
So for those who don’t know, unobtrusive JavaScript essentially means that you use JavaScript as sort of an optional add on, so the second central tenant is that the website will work even if JavaScript is switched off. It doesn’t have to be beautiful, it doesn’t have to be user friendly or anything, it just has to work, because if it does that then it’s accessible, it can be indexed by Google or other crawlers and, in our view, it helps the architectural model of the whole thing. And that means that you have to create HTML on the server side, which is probably the third tenet, to create HTML on the server side and then send it to the client and then you can use JavaScript to do fancy stuff. We found that we can build web applications that are just as interactive, just as user friendly as any single page app, but they still work on the web and they have additional features, like for example a working back and forward button, when the refresh button actually doesn’t return you to the home page and refreshes what you are looking at, and you can actually bookmark something or send somebody a link. So essentially you are building a web app that follows the REST principles as well as the useful use of the browser features. That’s something that we didn’t find a name for, we invented nothing here, we just enumerated certain traits and gave them a name because we couldn’t find anything else, so we are very open to discussion of that and we can find the link and there is an FAQ, it’s not an Innoq branded it’s really supposed to be an open kind of thing.
Sadek's full question: This is interesting. There is also, coming with this kind of apps, there is also another trend, people talk about real time web, and it has a lot of definitions, like what exactly is real time web but mostly people think about it in terms of open connections, open sockets between the client and servers and getting things from the server, you have web sockets before COMET, before we had COMET, long polling and server sent events and there’s kind of a debate about it, some people say it breaks the REST architecture, some people say it doesn’t break the REST architecture if you use it the right way, you should not delete the other components of REST architecture but it still can work, what do you think of all that?
First of all, I’ve heard a lot of people tell me that we are now going to build everything using Java Applets or ActiveX controls and then somebody said it’s going to be Flash, it’s going to be Silverlight, it’s going to be JavaFX, and lots of things that tell me the web is not good enough. Here people tell me that this boring old stuff that we have in the web browser is just not going to match the needs of people today. And I think that history has proven that to be a wrong assumption, the web wins maybe not because it’s so great, but simply because it has the most power behind it. So I think that there is definitely no trend that will make what we do today obsolete or replace it anytime soon. So I don’t think there is a real time web that now requires something completely different. I agree that there are certain scenarios where you just want to use the browser as a platform, maybe you’re building a high performance game, that has totally different requirements than in a classical information system, so I’m not suggesting you use the ROCA style to build an ego shooter or something that runs in the browser, that’s probably a stupid idea. Maybe there switching to something like web sockets, which normally is called an upgrade but to my view is rather a downgrade, you go from HTTP to just plain sockets, is suitable for those cases.
I don’t see most classical information systems, where you do transactions and interact with business information and maybe orders and customers and you do things that move money around, I don’t see that you need any of that. But the very rare occasions where you do, my favorite of those technologies would be servers sent events because it doesn’t break the web model, if it’s not something else, it’s a media type which I like, it’s a browser extension which is fine, so it essentially uses the facilities that we have on the web to deliver part of that functionality at least. Frankly, I think in most cases polling is just fine, I know people will shake their heads and say I’m just crazy, but if there is a hit once per second from some browser, what’s that going to do even if you have a few hundred thousand clients, if you have that amount of clients, you’re facing a certain load of the server anyway and then polling will not change it. You can use different technologies on the server side to deal with it that level of scaling obviously, but I don’t think that there is a necessity of switching to a push model for that.
I don’t think there is anything in the REST style that would prescribe anything here, you can essentially use whatever is appropriate for your application. I think that the key idea is that it’s still the client that initiates the connection, still validate HTTP call, it is still visible to the infrastructure it moves through, so I don’t think it changes any of those other things. Whatever you want to put as information into events will be up to your particular application.
So, first of all one thing that I like to point out is that there is from a REST perspective no difference between a web application that serves HTML to a browser and the web application that serves XML or JSON or whatever, to another sort of user agent. REST has always been the style of the web, so at the server side I think, it’s a very good trend to see that there are frameworks that address both, that we have a server side approach where it’s just different formats of representations that embody the difference and not some different framework or access model for that. I like frameworks that do that, for example Play will allow me to do that, or Rails allows that, we actually use JAX-RS together with a view template engine in many projects now to achieve the same kind of thing. I think the server side support can be much easier, maybe we need some add-ons, what’s coming in JAX-RS 2 or in Spring now with hypermedia making it easier to construct URIs and to do that. On the client side I think we need to have mostly JavaScript based, I know that there are many other languages but I don’t care that much for them, mostly JavaScript based components which you have as the key argument for many people to use something like JSF as the vast component library, I think we need a similar component library on the client side but I think the key requirement for that is that this stuff needs to be unobtrusive. I don’t want something that depends on JavaScript, but rather something that takes HTML from the service side and adds to it unobtrusively. You know there are libraries doing that, they all have some aspects that I don’t follow that model, I think will see more, I hope we’re going to see more of that.
So, I’m not sure. I think that this always has some downsides, I mean precompiling, having one level removed always has some downsides, that is being worked on, so that’s probably going to change. All those languages, I think I like CoffeeScript best because it maintains the character of the language, it doesn’t try to turn it, it doesn’t add a statically typed language on top of that, maybe just because I’m not that much of a fan of statically typed languages these days. So I somehow feel that both Dart and Typescript add something that I wouldn’t want to have, so maybe I’m not a target audience, I’d rather have people who feel like they need something like Dart or Typescript maybe get more into JavaScript and find out how they can actually use what they perceive as downsides as benefits, but maybe that’s just because I’m a dynamic languages fan.
Sadek: Alright. Thank you, Stefan, for this interview.
Thank you for having me.