Bio Stefan Tilkov is co-founder and principal consultant at innoQ. He has been involved in the design of large-scale, distributed systems using a variety of technologies and tools ranging from C++ and CORBA over J2EE/Java EE and Web Services to REST and Ruby on Rails. He has authored numerous articles and a book ("REST und HTTP", German), and is a frequent speaker at conferences around the world.
GOTO Aarhus is the enterprise software development conference designed for team leads, architects, and project management and is organized by developers, for developers. Important topics are presented by the leaders in our community. The conference concept is to present the latest developments as they become relevant and interesting for the software development community.
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.
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.
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.
10. [...]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?
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.
11. Right. And imagine this kind of application where I am using server sent event, what kind of message, to keep in the REST architecture what should I send through, all the information or links to the information, how should I use?
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.
12. Stefan, what is the kind of support that we need at the server side for building RESTful services and also what kind of support do we need at the client side doing this kind of web apps, RESTful web apps?
Sadek: Alright. Thank you, Stefan, for this interview.
Thank you for having me.