Hello developers.
And welcome back.
You can often hear people talking about REST API eyes or RESTful API eyes.
What does it mean in the generous framework talks we can find these puzzling quote You Keep Using That
Word rest.
I do not think it means what you think it means.
And then right below a couple of lines from the core depths.
First off the disclaimer the name jangle rest framework was decided back in early 2011 and was chosen
simply to sure the project would be easily found by developers throughout the documentation.
We try to use the more simple and technically correct terminology of web API use the word rest is the
acronym of representational state transfer.
It was conceived in use for the first time by an American computer scientist called a Roy Fielding and
his doctor out teases.
Fielding is an authority in computer network architecture and he also co-founded the Apache HDP web
server which I'm sure you probably heard about right.
And by the way you can find a link to fill this dissertation paper.
Among the other reference links for this lecture.
Remember you can download all the presents all the slides to the museum from the first lecture of each
section.
So with Resta fielding describes the specific architectural pattern for creating web APIs that use HDB
as their underlying communication protocol and that must conform to the following criteria.
First of all resources must be accessible via EU URL and points the EPA must use the Jason or X email
as file format.
They have to be stateless which means that basically a request cannot depend on any other requests and
must use age GDP verbs to perform actions verbs such as Get post put delete and so on.
So if rest is an architectural partner for creating web API is that use age GDP as their underlying
communication protocol and must use ETP verbs to perform actions.
Well it's pretty important to figure out what age should be release right and a GDP stands for.
I per text transfer protocol age GDP is one of the most important and popular protocols used to transfer
information on the web based on a system of requests and response messages.
In a typical client server architecture so the message exchange takes place typically between a browser
accessing a web server or a client app accessing a web API dough client and server can be anything really.
Just think about smart fridges or smart toasters.
You know what I mean.
So this is a diagram of request response cycle in HDB client and server communicate by sending plain
text messages where client sends a request.
The server processes a response and that sends its back to the client.
What does that request message look like.
The request message consists of the following.
First of all a request line that describes the request to implement.
Now we have the request.
Other fields which might contain additional information about the request.
Then we have an empty line which signals that the meta information meaning the information about the
request itself have been sent and then we have an optional message body.
This is an example of a request line using the age TTP get method.
Some people call them request a start line.
OK both are ok to use.
We got the method.
This case is get.
There we go.
There you are right.
Which just basically use it in defiance of the resource that you rail.
This case is the home page of Google and now we got the protocol a repeat and the version one point
one.
So far we've seen our web API is exposed the web apps functionalities and components via U.S. rail and
points so that they can be accessed by external client taps or by other parts of the same web app.
Oftentimes there's functionalities we know so correspond to different types of actions to be performed
such as retrieving information about a specific tweet or creating a new blog post based on some data
based on the API.
Of course we've been JS to an object.
We might also want to update the information about an event for example saved on our calendar rap or
maybe delete the appointment altogether.
So as we've said different types of actions to be performed let's talk about request messages and rest.
Let's find out what really works.
So by convention in arrest API the TTP request method that we use will correspond to the kind of action
that we want to perform.
We will use the get method to retrieve a resource the post method to create a new one put or a patch
to update the resource and delete.
Of course to delete a resource where in the context of the rest api the resource represents a data entity
such as as we've said a tweet a blog post a product and so on.
What does the response message look like.
The request and response messages look very similar a response message consists of the following.
First of all we've got a status line which contains the request status code.
Success or Failure.
Then we got the request at airfields which contain again additional information about the request.
Then GMT line and of course an optional message body.
So very very similar.
And this is an example of when each GDP status line we've got the protocol and the version and then
the status quo in this case 200.
OK.
Everything is all right.
Here are some examples of statutes codes on the left and on the right.
We go to five status code groups so we have something very common like 2 and red OK which informs our
client.
The request has being successful then for example after a post request.
Let's say that we've just created a new instance.
OK maybe over a blog post we might get back day details of the same post we've just created.
Ended it well one created code which has SAS Yeah.
They used this as being successfully created.
OK.
Then we might get some AdWords OK like for Android but the request or maybe the forum for not found
that it's pretty come when you know everybody knows for or 4 and on the right we find a five star TOS
called groups because as you might have noticed you know all the codes that are in the 200 okay represent
requests that have been successful that we've got the one on there are information out three hundreds
that are right direction for Android's client errors like for example not found.
Maybe we were just looking for a page that doesn't exist or the five hundreds that are instead server
error.
Like for example you might have seen five or two something like that because maybe the web server like
engine X has been mis configured.
Okay so to wrap it up in a nutshell let's see a couple of examples of requests to an online source RESTful
API.
Okay so for instance we might go to slash products using the get h UDP verb and we might expect to get
at least with all our products in a Jason format.
In this case the status code is going to be to Android.
Okay then we might go to slash products slash 17 for example a primary key.
And if this product exists.
Using to get h DDP verb we might get the details of the product we have primary keys 17.
Of course it's time using the Jason format.
Okay in the status code just as well is going to be most likely to undo it.
Okay then let's say that a product has been maybe suspended or deleted or maybe just doesn't exist.
Okay.
Making a get request to slash products slash a primary key of a product that doesn't exist will result
in an error message.
And of course no product needs status code.
In this case could be for or for not found there.
Let's say we wanted to create a new product.
Okay we might go to slash products.
Okay.
We can use the same endpoints to perform different actions.
As long as we're using of course a different age TTP verb as we're going to see more details of course
as we said we will drive a creation of a new product and days to this go to or one created.
Then let's say we wanted to update a product.
Okay.
We will have to use their put HDTV verb going to the proper you are relevant point.
In this case could be something like Slash products slash 15.
The same pattern if we wanted it we've use to get the details okay but this time we're using the PWD
verb.
Okay so we might get an update to the product ESB primary key 15 to Android.
Okay.
Is status code of course in such cases for both post and put requests.
E if we wanted to create or update a product we would have also to send the details about the product
in the message board.
Okay.
And then if we wanted to delete the same product.
Okay product with a paramedic 15 you will have to goes to slash products slash 15 H DP verb D2 it would
expect of course the deletion of a product the instance with primary key 15 and as status code to 0
4.
No content.
Okay everyone that was ead for this lecture I remember you that as always by the end of each lecture
in the corresponding PDA files you can find several reference links that I really suggest you go and
have a look at.
Okay take your time to properly understand all the concepts that we talking about so that you can feel
confident and really master all these keys that you're going to get out of this course.
So that was it for this lecture.
I hope you enjoyed it.
See you in the next one.