 Okay, now that we know what the layered architecture is we go into what rest is and rest is a so-called architectural style for network-based application software So for anything that runs on a network like the internet And nowadays most of our applications are somehow network-based, so it covers a lot It's something that was originally developed by Roy Fielding a guy that did his PhD on this kind of topic and what This style does is it tells you how to structure software that runs on a network, so how to Basically decompose it into pieces and how they should communicate so that it's effective Basically nowadays a lot of these kind of network-based applications are web applications that use HTTP or HTTPS So it's a very common use case and that's why it fits into this course it is Used heavily in the design of the HTTP standard and how your eyes are structured, so That's why I have that later But that's why a lot of the things I talk about you sort of you will recognize from the way the internet works So it's sometimes a bit difficult to to get across the point What's so special about this style because a lot of you know many of the things Rest is a is a combination of things. So it's not like a completely new invention Basically, it's a smart combination of existing styles how to structure system One thing rest does is it talks about resources all the time So everything is somehow a resource and that's sometimes a bit difficult to understand. I already mentioned that in the second Lecture and we said HTTP returns a resource, but we'll get into more depth on that Now if we let the guy speak himself Rest is about scalability. So we want to be able to scale our applications And the interactions between them and that's exactly what we have in the internet, right? You can have a lot a lot of interactions a lot of requests at the same time and it's built in a way that's scalable We can have many users The interfaces should be very general So it should you shouldn't have inside knowledge of each application to figure out how to call certain things Then very important independent deployment of components And that's a very important thing in the internet again. We have a heterogeneous Infrastructure so we have different hardware different network standards different operating systems And this style is made in a way that this is easier to do Intermediary components so we can put stuff in the middle that somehow helps us to reduce latency That helps us to make systems more secure And a very important thing it helps us to encapsulate legacy systems. That means We often have systems in the internet that have been running for a long time and it's hard to replace them You don't you cannot rewrite the whole system. It takes a lot of effort And the rest style helps to sort of put a server in front of it so that you can adapt it to maybe a new Interface and a new kind of way of calling it but in the background actually the same old system is still running So you do not have to reprogram it you just sort of slightly change one component in your setup now rest is just a style of structuring a system And you often read about restful web services So that basically means you have a web application a service in the web that is built according to the rest style But rest is not exactly the same as a web service So you can have an application that is strictly speaking not a web service, but it still follows rest so This is confused a lot in the internet when you read blog posts and so on but rest Per se is not only about web services. It's a general way of structuring systems now rest stands for Representational state transfer And that's a bit of a confusing acronym But what it means is we transfer something we send something across the internet And what we transfer is a representation of the current state of a resource Now that does not help a lot I assume so let's go into depth here Let's assume You request a minesweeper board not broad so Assignment to you request a resource in our case. That's a board that tells you how the minesweeper thing looks like the server Sends it back to you it transfers something And it sends it in the HTTP response. So that's the first part of our acronym What the server actually returns is a representation of the board It does not return exactly the same data as in the database For example, it might not return all the IDs like the MongoDB database Internally has has another ID that depicts which version we have or there might be in the minesweeper case I don't have that but we might want to add information about how to solve the board. So The server just returns some kind of representation of that So I could send in our case. I sent back a JSON string But I could also send back a picture for example, that would be a different kind of representation So that's a difference. I don't return exactly the same as in the database I return some kind of representation of it and then finally I return the current state So resources can change over time If I would go in and change the board Manually for example, then the same resource the same minesweeper board suddenly has a new state And the next time you do the same call again, you get a different representation Because the change the state has changed So that's really what it is about. We transfer something which is a representation of the actual resource And we always return the current state of it Now the rest style comes or is defined as a number of constraints as a number of things you have to do If you follow these constraints, you are restful. Your system is restful There is one exception and that's number six that is defined as an optional constraint So something you don't have to do Now as I discussed earlier most of these things you have seen before So there might not be that many surprising things and I'll go in the following. I'll now go through them Five I'll do last because it's maybe the strangest one or the one you haven't seen before Okay number one client server so Rest says the system should be built as a client server system Um, which means there is a server that responds to requests. It does not send requests itself Back to the client. So it just answers. That's a general setup It's essentially as the idea is its separation of concerns So many user interfaces here can use the same server The same data the same business logic. We don't care Also the user interface the front end can evolve separately so I can change it The server remains the same And that's great because I can for example have different teams working on these two components And then finally talking about the heterogeneity of the internet My server code can run in a completely different environment in a completely different programming language on a different operating system than my client So again, we have seen this in the assignment two examples My back end my mind sweeper generator does not care about what hardware you have what operating system you use and so on It's separate The second constraint is statelessness. So That means Whenever you send a request it contains all the information And that's now a bad example because in the mind sweeper case we we did not use that But for example, imagine you are in the gmail application and the first request you send is Login. So you want to log in That's the first thing you do. The second one is for example List the emails Now there are two ways of implementing this you could say First you log in Then the server or the client remember that you're logged in. So when you send list email It says, yeah, you're logged in here are your emails That will not be stateless because the server or the client would have to remember your first request So the second request depends on what came before Now what happens actually in a stateless system is you do the login You get some kind of information back We'll cover that in security, but quite often it's like a number a token That says this is your login information and the next time when you say list email you have to send this information along So you say for example, here's my token And then the system Doesn't remember this request. It doesn't need to know the only thing it needs to check is is this token correct or not? If yes, then list the email And that means each request contains all the relevant information That's an extremely good thing per se because For example, if you want to debug something is wrong You only need to look at one single request if My second request here depends on the first one if the server needs to keep track of it Then I need to debug the entire history Because something could go wrong in the first request something could go wrong in the second one But that's not something I have to do here The next thing is reliability If I have a failure if I if there's an error, I just need to re-send the last request If I would have a stateful system that something remembers then I might have to start from scratch and first do login again Then do list emails again and so on. So it's more reliable. I need I don't need to re Send everything. That's also a good thing for testing. I can test things separately And then scalability is is probably another issue If the server doesn't need to keep track of the clients and what they have done so far and where they are It's much easier to build distributed applications because I could have Multiple servers that do the same thing. So I could have another machine here And yet another machine and it doesn't matter whether the request goes to the first The second or the third thing it doesn't matter because all the requests have all the important information If it would be stateful and I would for example login on server one Then server two would have no idea about that. So I would somehow have to handle That server one tells server two about it. If I have a stateless system, that's much easier We don't have to care about that So it's easier to build distributed applications, which is again a very important thing in the internet There is one issue with this. So most of these constraints are not perfect. They are trade-offs And the issue is the network traffic If you need to send More information in each request, of course, there is more network traffic There is more stuff you need to send over the internet So that's a disadvantage we have Um That's something we have to live with Now the third constraint is cashability. So This means if I do a request The server needs to send back in the response. It needs to tell you Can you cash this request or not? So basically, uh, it has a yes no flag here that says yes You can cash this or you cannot Um What this means is the client knows If I sent the same request again Do I actually need to send the request or can I reuse the last response? So I save Network traffic. I save time If I don't have to do that again Uh And the user of course thinks that's great because the answer sort of arrives quicker in reality I never send a second request. I just reuse the first one But it just means the response has to have some kind of information about whether or not something can be cashed There is again a trade-off with that and that's reliability So if I have implemented this in a bad way, then it could be that the client reuses information that is outdated So for example, uh, I have a website that changes all the time For example, it has live weather information Uh, and if I tell the client you can cash this website for up to two days Then the client would always get Uh, weather information that might be up to two days old. So this might be unreliable. So that's the disadvantage here Constraint number four is uh, basically follow the layered architecture style So that's Exactly what we discussed before use a system that is somehow layered No direct calls across layers. No backwards calls Um And the advantages are as we discussed earlier, you don't need to know the upper layers The back end doesn't need to know the front end the database doesn't need to know the server Uh, many upper layers can use the lower layers and it's easy to replace and to add and remove layers So that's uh, there's nothing new here. That's just what we discussed earlier The trade-off is uh There's always a trade-off here We have additional overhead if we could do a direct call to the database it might be quicker Uh, so there is more there are more HTTP requests. There's more processing going on Compared to doing it directly, uh, which might take longer because each request takes time each processing takes time That's a disadvantage Okay, now we jump over the fifth one. I said I'm doing that last and we go to number six So remember this is an optional thing. You don't have to do it But it says You can send executable code back to the client code on demand And this allows the client to be extended with additional functionality So our business logic does something but on top of doing something it can also send some code to the client to the client and execute it And that's the advantage the client does not have to implement this functionality because it comes from the server already The trade-off is somewhat visibility I mean the code Is being sent to the client so the client can of course see the code can change the code and so on This might sound like a very strange constraint to you because Uh, we have been doing this all the time. So every time we had an html file then included javascript That's exactly what we did. We sent the javascript file to the client and the browser executed it So that's something we already did a lot But i'll do an example later based on html which explains all these parts Now finally, uh, we have constraint number five Which is called uniform interface. What this says is there should be a uniform way a general interface that is used by all the clients So whether you're you have a laptop or a mobile phone or another server you call exactly the same Interface in the same way and it doesn't matter where the request goes if it goes to a Small server a large server or the post office the call is exactly the same That's actually one of the key differences to to other existing styles for network systems Um, but it's again something that you're very used to so you might not be Seeing the point here directly. This one has four sub constraints, which I'll go into There is again at disadvantage and that's efficiency if you can tailor an interface specifically for a component It might just be more efficient. It's not as general. It cannot be used by everybody, but it's very Suitable for exactly that component. So for example, if you use a mobile phone to Send something to the post office. You can do an interface that is specifically designed for that If you do the same interface to work with all sorts of servers and all sorts of clients It has to be more general Which might not be as efficient Okay, let's go into the sub stuff There are four of them. The first one is about how do we identify resources? So how do they look like? What's the naming of them? Second one is called manipulation through representations, which we'll get into self descriptive messages And then the horrible acronym, which is called hyper media as the engine of application state. Hey, do us That's a tricky one. It's hard to understand The acronym is even more confusing, but I'll tell you all about it Now First one identification of resources. We already talked about that rest is all about resources. Everything is a resource And what we mean by that is typically business objects something in your business domain, whatever you are programming That exists if we're doing a mind sweeper application or a mind sweeper board Is a resource if we do the solution to the mind sweeper thing that might also be another resource In the internet, we have documents. We have images if we have For example, assume you have a logistics application So something that allows you to make orders and maybe send things then maybe we have resources like order or payment We will later on take a look at the PayPal API Which has these kind of things you can order in PayPal. You can make payments and so on So it usually depends on what kind of business are you doing? What are you implementing? Those are your resources Every resource in rest can somehow be identified. So it has a uri And this is again something you have seen on a website. Each image has a specific url There is some kind of way of addressing that image of identifying it. That's exactly what it is here In the mind sweeper case, there has to be a way to create mind sweeper boards there is Even the way actually to receive a board with a certain ID There is some kind of way to identify Each and every board And of course in PayPal is the same if you create an order you have to somehow identify to do something with it So that's the first thing. We want to be able to identify our resources Then We want to Encapsulate them. We don't want to directly interact with the data. For example, directly do database calls Instead what we do is Sending representations. So that's what I discussed when we when when we discussed what rest stands for That we only send back a certain representation of the data Instead of the actual mind sweeper board in my database, you get just get a jason representation of it And if you want to change it In the mind sweeper case, you cannot But in many other cases if you want to change the resource if you want to modify the payment in PayPal You send back jason again. You send. What do you want to change? You do not directly send back. Okay, please take this new piece of data and write it into the database Instead you tell the server how to change it Now self descriptive messages is a very important one that makes it easier to use things the idea is Every request can be understood by the server in isolation as all the information what we need For example, what kind of representation Do I want to have if I send to the server? Please give me a new mind sweeper board I might have to tell the server. I expect you to send jason back because that's what I understand When we use HTTP we for example, that's one way of doing it We typically use the verbs the different methods get post and so on to tell the user to explain How we are what we are Planning to do with the resource so for example if we do a post request We say please create a new resource if we do a get request We just say please read the current state. Please give me the thing back so Again in mind sweeper what you're doing is you do a post request So you're telling the server. Please create a new mind sweeper board and send it back to you There is another call which I have not told you about but in in my application. You can also do a get call And tell the server, please give me the board with a certain id Then there is not a new one being created But it checks in the database. Is there a board with id 5? If yes, send it back So we often use these verbs to identify what exactly we want to do. That's one way of having Messages that are very clear. They're self descriptive. You don't need to understand The api in all detail to know what it's doing and we'll be seeing that in in the paper api Last one Hey to us Forget about the acronym because it's really just a horrible weird way of of describing what's going on What it's all about is essentially whenever you return a resource for example mind sweeper board You also should send back a number of links That tell the the receiver what they can do with it So this is something I haven't done and that's something most people don't implement in their api But what I might do for instance again in the mind sweeper case if you do a post request So you basically tell the server create a new board What I should have done is Send you the the resource back so you get somehow the the board id Five And you get the actual board and so on and then additionally what I might Have sent back is something like links That says okay with this board By the way, you can also do the following you can actually do a get request so if you do get And then a url if you do get five Then you're Additionally able to read the board in the future So it's basically just a way to provide additional pointers what you can do with the resource So in this case you know that you can create one, but then you get the board back and you don't know what else you could do If I add these links, I might be able to tell you well by the way you can also get it You can also delete it. You can also do whatever so it's kind of providing additional links So that's now An overview of what the rest style is and I would expect that by now you are pretty confused of what this actually means So we'll do one example, uh, which is the most common one the one that you're most used to that's just the way Websites work, so we'll look at that because websites htdp the internet follow the rest style And then later on we'll have a look at More practical advice. We'll design a rest api ourselves so Websites htdp is the main protocol in the worldwide web And rest has been used to develop htdp as I said So that's why we see all of these constraints in typical websites So the first one is the client server constrained That's what we do all the time. We go to vikipedia and say, please give me the website the resource That tells me about URLs That's exactly what we do the browser then receives the html file. It draws it. It renders it and you can interact with it Stateless this constraint is fulfilled because htdp is stateless. So that's what we discussed in lecture two By default there is no state in htdp requests, which is for example very different if you look at the tcp protocol So the tcp protocol is sort of first initializing a session a connection to another server Then when that is done, you can send data and at some point you close the connection again That's very stateful htdp is by design stateless cashable Uh in htdp and maybe we'll just look at that if we make a request Let's go into my network view Uh if I for example go to vikipedia And I want to know about url um I've done a request and if you look at the response headers here what it says is cash control So this tells us about how can the caching be done and I won't go into the details Uh, it might go there might be a number of other things cash. That's a bit of uh details but essentially The htdp protocol has In its headers, it has a way to tell me about yes, you can cash or you cannot cash So that's built in into the protocol. Uh, so that's our third constraint um The fourth constrained layered system is also implemented in in this case When when I sent the request, I only know the target url I know that the the url is vikipedia.org slash something Uh, I don't know where this url gets the data from so most likely Behind the the vikipedia server. There's a database or a number of databases And it makes a call there and it gets the data back But I have no idea about that. I don't know where the database is And I don't know how to access it either And that's of course a great thing because if I would be able to directly access the vikipedia database, I might cause a lot of harm Now the uniform interface, uh, is again something that's in built in htdp It's just that we have urls. They are a standard way of identifying resources. So The the u in url stands for uniform and that's exactly what we want to have so the there they are somewhat, uh descriptive I know that if I put, uh If I write a url here, I know that okay, this is the server. This is the protocol And this is the path for example They are somewhat self descriptive If you know details about how the urls look like you are able to understand What it is you are calling And then finally we have the codon demand thing. Well That's as I already said We are loading one resource in this case We are loading the html file But as you see here in the network view, there is a whole lot of other stuff that is being loaded like css javascript More css and that's actually codon demand. We are downloading the server sends us Uh additional code that we are executing on the client side So that's exactly just the sixth constraint Uh, so websites are a very very common way that implement the rest style If we dive if we dive into the details of the fourth constraint, uh, we can look at at all the details So I've already said we use urls. What we actually do is we identify resources We have a unique way with the url to identify what we want to have Uh If we manipulate anything So for example, if, uh, something is changed On the database side data in the database only the representation is sent. So for example, if we uh, if we want to create a user account We do a post request and we send some kind of, uh, body Username password and on the server side something is created some user account But that's not exactly what we send over. So we just send some kind of representation the post body Uh We have somewhat self descriptive messages. So the werbs in htdp tell the server what is going to happen Is it a get request? Is it a post request and so on? uh And hate to us is actually I would say that the clearest case is html because We have in an html file. We have lots of links To other things. So of course, you know all of these things That's basically hate to us. It's telling us what else to do Where to continue from this resource? So we have we don't have to know the details of all the different resources on vikipedia That's what the links tell us. By the way, you can also read about web resources So that's hate to us, uh in the website case All right, so This has been fairly abstract So either you have been confused by it or it has been obvious. So why why do we even think about this? Or both So the question is really what do you get from rest? Uh, and Would like to go back to the the original definition The constraints we're having really give us the scalability we have in the internet So that's why the internet can grow so well The URLs help us to to navigate the internet. They really make things clear But we are very used to it independent deployment is something we don't even think about But we have all this separation in the internet that we have clients server side databases load balancers caching and we don't even see them and All of this is essentially Why the internet works so well why it scales so well? And also why it's so heterogeneous. It it does not depend on a single organization to run it or something like that And that's really the power of rest now That's why the internet works. That's all fair. We know that it works But we now get into how we build our web applications in a restful way. So Similar to the internet the internet is scalable the internet is general If we build a web application in a restful way, it means this application is most likely scalable It's fairly general. You can understand it It's easier to change. It's easier to maintain them other applications And if we do this if we build a back end that is following the rest principles Then we have a so-called restful api or a restful web service. So that's what we're going to do To do that, we'll use one of the many checklists because rest is quite abstract So if you want to build a web service, you often have these checklists like number three that tell you concretely What should you do? I only cover parts of them because I think some of them are more relevant than others Or they may be so advanced that they don't belong in this course, but rather in that web services course And what you'll see is there are a lot of checklists out there that talk about how to do rest But most of the practical advice has nothing to do with with the actual rest style So you can implement rest in a very different way We anyway, this practical advice is usually useful So we consider them sort of to be part of the best practices. So also when I Discuss in the exam or in the assignments to follow these best practices Then it means also follow the practical advice that has nothing to do with rest itself Okay, so this was the theoretical part of what rest is and what it gives us Now in the next recording we will start building or designing a restful api For a certain application and then in the last part I will just show you an example of the PayPal API Maybe another one just to show you that if you follow these rest styles You do not have it doesn't take a lot of effort to understand how web services work If you follow the best practices, the web services are sort of self-explanatory But we'll see about that later