 Welcome to lecture 15 and 16, which is all about REST. Part of this will be very theoretical, but then later on we'll look at some more practical examples. Now, we start off with some basics prerequisites for REST. In particular, I cover layered architecture, which is an architectural style very common in web systems. That's what this first recording is about, and then we dive into what REST stands for, why we have it, and then go into some details, how to build RESTful APIs and some examples on that. I again have the whole list of learning outcomes for the block lecture 14-17, so that's exactly the same, but in particular here we look at the constraints of REST and everything related to REST, essentially. There are three references that are important. The original PhD thesis that introduced REST is the first one. Chapter five is really the interesting stuff for this course. There are some details there. There are some, in particular, some explanations of why we have certain choices in REST. So if you don't believe me or if it's too brief, that's a good source to look at. The second one is a very short book. It's about 30 pages in total, including table of contents, bibliography and so on, that introduces REST, and it's a very nice reading, and I refer to a lot of that. Then the same person has done a checklist on how to do REST APIs web services that follow the REST principle. I don't think it's the best checklist that exists, but it's the same author, so at least it's not conflicting with this book. The second source, the second thing is exam relevance, so please read that. The booklet is two or three years old now, so many of the examples might have changed because they give some examples to real-life APIs, but they are still very valuable for understanding, so you're just not able to go in and test them. Okay, let's dive right in. We start off with late architecture, which is a style of structuring a software system, the architecture, that's the overall way the system looks like. And as the name suggests, we are putting layers into our systems. The idea is that the lower layers provide some kind of service to the upper layer, some kind of functionality, and calls, if we call any functions, are going top-down. So basically a lower layer provides something that is then called from the top, and it only responds. It only responds, it does not call back, it does not call a function in the upper layer. So that means the lower layer provides something and it doesn't have to know what's on top of it, it doesn't care. It only replies. And it also means that you can have many upper layers that can use the same lower layer, because the lower layer doesn't need to know who's using it. The next important thing is that a layer only knows the next one. So if you have three or four layers, then the first one only knows the second one. It doesn't know anything about the third or fourth. So that makes it easier to replace layers that are somewhere in the middle, and it makes it easier to add and remove layers. So what does that mean? Let's make an example. A very common thing we have in the web is the so-called three-tier architecture. So it's a layered architecture with three layers. And at the very top, we have the presentation layer. That's really what we have done so far. We have HTML files. We have JavaScript. We have CSS. It's all the stuff that the user directly sees. Now, the second layer is the business logic that sort of the server that the presentation interacts with. So for example, in the second assignment, you have the Minesweeper service here at the second layer. So that's where you send the request saying, please give me a new board. And it can be in many different languages. I implemented it in JavaScript with Node.js. There are many other frameworks. You can, for example, use Java Spring. You can use PHP. There are many languages, many technologies to implement that. And then finally, we have the database access layer. That's where we store our data. So in many of you are currently taking the database course where you cover SQL. So you could just have a MySQL or Postgres server or something completely different like MongoDB, which we'll be using here. Now, the important thing is we don't have any upward calls. So for example, the database should never call the business logic. It should not know about it. And the good thing about that is you can have many business logic layers that use the same database. So I could just implement another thing here. For example, last year I had a backend that did Sudoku's. So I could have a business logic layer, a web service that generates Sudoku boards, and I can save them in the same database. The database doesn't care. It doesn't know about them. And the same, of course, goes for UIs. You could have another presentation layer to the same server. So for example, one student could implement a solution to my Minesweeper backend and another student could implement a solution here. And my backend does not care about that. It doesn't know. So my backend never calls you back. It only replies to function calls. The other thing that's very important, that's the other red arrow here. We never skip layers. So you never go from the presentation layer directly to the database, for example. And that's, on the one hand, a security thing. So we cannot just mess up, put something dangerous into our SQL table, send a command that erases the whole table, for example. That's one thing. The other important thing is you don't have to know the technology here. So for example, right now, you are just calling the business logic to get a Minesweeper board. You neither know nor do you need to understand what kind of database I'm using. So I am actually using a MongoDB database to store your Minesweeper boards. But I could just decide someday to switch to an SQL database. And as long as I fix this one here, as long as I fix my business logic that it knows how to access the new database, you will not notice the difference. So it's easy to exchange a layer without you knowing. But that's only possible if I don't call backwards and if I don't jump over layers. So that's a very common thing I can do. So that's the three tier architecture. And this is exactly the situation I just described. We have the front end, for example, your solution to assignment two. We have a business logic or a back end. That's my Minesweeper generator. And that Minesweeper generator saves stuff to the database server, which in our case is a MongoDB database. Now, the back end doesn't know about our front end. And that's good because we have 300 students developing different front ends. I don't need to change anything to accommodate for that. The second thing is you do not know the database. I cannot directly call the database. So I can replace MongoDB today with something else. You will not notice the difference. I can also add a layer in between. So for example, if this would be a very performance intensive thing, I could add something like a load balancer. So a server in between that divides the loads between different databases, for example, I could add a caching mechanism that makes reuse possible. Or a very common thing as well is I could add a security layer here that does some kind of authorization checks that I cannot just access the database from everywhere. And you will never notice the difference. So that's a very important advantage of a layered architecture. And we just here, we just call it three tier because we have one, two, three layers. But of course, if I add a security layer here and a load balancer and a caching, then suddenly I have six layers. So this is just a layered architecture with a number of layers in between. And just as well, I could, for example, add another back end here that provides some other kind of functionality. For example, a back end that generates solutions to my Minesweeper, which for Minesweeper doesn't make a whole lot of sense, but that's something I could do. Okay, so this is the most basic introduction to what a layered architecture is. And that's one of the prerequisites for what we'll use in REST. So that's why it's important to introduce this. And then the next recording will now start going into what REST means and why we have it.