[MUSIC]
Let me give you a brief rest.
Got you there!
What I meant to say was,
let me give you a brief overview of representational state transfer.
What exactly is rest?
How do we make use of it in our angular application and
how do we make use of this to communicate with the server?
How does a server support REST API and
how do we access the REST API from our Angular application?
Let's talk about that a little bit more in this lesson.
In this particular lecture, I will give you a brief overview of REST.
I'm sure you've heard the term Web Services being mentioned
in the IT world very often.
What exactly are web services?
Web services are a way of designing systems to support interoperability among
systems that are connected over a network, like the Internet as we see today.
This is what we refer to as a service oriented architecture.
Now, what this means is that you provide a standardized way for two machines
that are connected to the internet to be able to communicate with each other.
Their application layout level for
database applications using open standards.
Now, I have used a lot of jargon there.
Let's try to break them down and
understand a little bit about each of that in this lecture.
Two common approaches that are used for supporting web services are SOAP,
the simple object access protocol based web services,
which uses the web services description language for
specifying how the two end points communicate with each other.
And typically, soap is based on using XML as
the format for the messages being exchanged between the two endpoints.
The presentational state transfer or rest also uses web standards, but the exchange
of data between the two endpoints could be either XML or increasingly.
Using JSON as the format.
The REST way of interoperability is simpler compared to SOAP and
hence REST has found a lot wider deployment in the web services left.
Typically, client server communication is facilitated using REST
where the server supports the REST API and the client can then invoke their REST API
endpoints in order to obtain information or to upload information to the server.
Again, I have mentioned the word, invoke that REST API end point.
So these are a few terms that I have used.
Let's clarify some of these in the next few slides.
Representational state transfer is a style of software architecture that
is specially designed for distributed hypermedia over the World Wide Web.
Now this was first introduced by Roy Fielding in his PhD thesis.
Now, this is one of those PhD thesis that actually produced
something useful for the world.
So this has found again a lot of traction in the web services world.
This is a collection of network principles that outline how resources can be
made available on servers, and these resources can be accessed from clients
by identifying the resources using REST API endpoints.
Within Representational State Transfer there are four basic design principles.
First and foremost, REST is built upon HTTP protocol.
So it uses all the HTTP methods That we have already seen in the previous lesson.
Second, REST is designed to be stateless, meaning that the server doesn't store
any information about the state after the communication is completed.
So when a server receives the request, the server replies and
then after that, it doesn't remember anything more about that
conversation between the client and the server.
Third the REST way of providing resources is to
expose a directory structure like URLs uniform resource locators URLs.
And fourth their format for data exchange is typically JSON or
XML, or both that can be supported using REST.
One of the motivations for rise suggesting REST as a way for supporting web
services is that it captures all the thing that are good of all the World Wide Web.
And that made the Word Wide Web successful.
The use of Uniform Resource Indicators or Uniform Resource Locators, URLs,
which allow you to address resources by specifying them as a URL,
the second one being a protocol that rides on top of HTTP protocol.
HTTP has already found wide deployment in the Internet.
Third, the request response cycle that HTTP is well known for.
So you send a request, the server receives your request, processes the request,
sends the response to the request, and that client receives the response,
acts upon that, and may generate further requests.
So, this approach of the request response cycle is very well established with HTTP
and the worldwide Web THe HTTP protocol as we have seen earlier,
we will use all the various verbs that HTTP provides.
Specifically, the gate put post delete.
For being able to specify operations to be done
on resources that are stored on the server side.
So for example, if you do an HTTP GET request, you are asking for
the server to return the source.
If you do a POST request, you are asking for the server to create a new resource.
If you do a PUT request, you are asking for the server to update
an existing resource and if you issue a delete request you're asking for
the server to delete the resource that is identified by that particular URL.
Also, it tries to preserve idempotence.
Some operations when they are performed
Even repeatedly will not cause any change of state.
Some other operations, if you do them successively,
they may cause a change of state.
So you need to be careful about which operations can be repeated without
any damaging consequences.
And which have to be very carefully done.
In the REST world, you often hear people talking about nouns,
verbs and representations.
Now we'll clarify each one of these in a little more detail in the next few slides.
Nouns, specifically, they're full of resources and
these resources are usually identified by their URL's and these are unconstrained.
Verbs are constrained and these specified actions to be done on the resources.
And the presentations as we see when the information needs to be conveyed from
the server to the client or
from the client to the server, how you encode the information.
Typically either using JSON or using XML.
Resource is the key abstraction that REST works around so
that information is abstracted in the resource.
And the resource is identified by specifying it by using a URI.
So any information that can be encapsulated and
be made available can be identified as a resource.
A piece of information like that current weather in Hong Kong could be a resource,
an image could be a resource.
A stock price information could be a resource, and so on.
So whatever you define as a piece of information that a client may be
interested in, can be identified as a resource.
You can even deal with resources as collection of resources
that that server may send up to that client.
An example of how you name resources is illustrated here.
So we use URIs to identify the source.
A quick reading of the specification or the URLs here will
easily enable you to understand what we are referring to by using these URLs.
So for example, something which ends with dishes/,
you automatically assume that this is referring to a collection of dishes.
Like dishes/123 for example,
might mean dish number 123, in this case and so on.
So it's very easy to say that you can specify a collection of resources, and
be able to identify them as a collection, and then download them as a collection.
Or, you can identify an individual resource, and
say that you want that particular resource.
Now these resources can be organized into a hierarchy
that specification of this URI.
So as you traverse the path,
you go from the more general to the more specific of that resource.
This directory structure enables you to identify the resources that
you provide from your service site very easily.
The second part of the REST API are the words.
In particular we are interested in the 4 verbs of HTTP to get,
put, post, and delete.
In this case these verbs will be nap in to actions that we
want to be performed on the resource on the server side.
GETt would mean you want to perform a read operation on the resource, which means
that a client sending a get request is indicating to the server that it wants to
obtain that presentation of data source from the server site to the client site.
POST means means you want to create a new resource and then you will.
Specify the details of the resource in the representation, but is used for
specifying the resource.
Then send the information over to the server side, so
that the server will create the resource on your behalf.
A PUT would be modification of resources, and
delete, as you would expect, is deletion of the sources.
So, as you can see the four Verbs get, post, put and
delete are mapped into the four CRUD operations that you can carry out
on a database that stores these resources on the server side.
The read, create, update and delete operations.
Elaborating further, the HTTP GET is a way of specifying.
That you want the information or their presentation of the resource to be
returned to the client from the server site.
So when you issue a GET request to a REST API endpoint.
You are asking for either a collection of resources that are presented by
Uri or a specific resource which is identified by the ID of
that particular resources specified within the URL so as you see in this example,
if you dishes/452, you are meaning to say that dish number 452,
with the id 452 should be returned to the client side.
Similarly, the post operation, as we saw, is used to create the resource.
So when you create the resource, the content of describing the resource would
be in the form of a JSON representation or a XML representation, and that would be
included in the body of the request message that is sent to the server side.
So a post operation expects a representation
of the resource in either JSON or XML format in the body of the request message.
And the server receives such request message, the server creates that
resource on the server side and then returns either a confirmation or
a error to indicate that the resource creation failed.
Similarly it put operation easy use to update a resource.
When you do a PUT operation on a resource on the server side, you may send back
the modification either by specifying only the partial modification
that you want to effect on the particular resource in body of the reply message.
Or you may send the complete representation of the resource
in the body of the message, depending on the arrangement between the client and
the server, the server expects the information to be
passed on in the body of the request message.
DELETE operation as you would expect deletes the existing resource.
Now in this particular case, of course, a delete operation would be because
if you try to delete a resource and the resource exists, it will be deleted.
If you are trying to delete a non existing resource,
it won't cause any further modification to the server side Except
that the server will reply with an error saying that the resource doesn't exist.
But nevertheless, is an example of an operation in this case.
Similarly, the get operation will also operation because it is not
making any modification to the resource on the server site.
Post input of course are going to modify the resource on the server side.
You need to create a new resource or
modify existing resource on the server side, and of course data presentations.
As I have been emphasizing, the two common fallbacks for
representing is either JSON XML, the last part
that we need to emphasize is that server side should be completely stateless.
Which means, that the server side does not track the client's state.
Because, if the server needs to track the client's state, it will not be scalable.
So for a scalable implementation of the server side,
you normally use a stateless server on the server side.
So if the request of the clients sent to the server will be treated as
an independent request, and will not reflect upon previous
requests that have already been handled by the server from the particular client.
So it's the responsibility of the client to track it's own state.
Either in the form of using cookies or using a client site database.
Whatever means that is suitable.
Now, this approach where the client tracks its own state is a lot more scalable,
because your client will be responsible for tracking its own.
And this is where the client side MVC setup helps us in this regard.
And finally we are not yet done with REST, we will see more of
REST in the exercises that follow in this particular lesson.
And then also,
we will see more details about REST usage in the rest of this course.
[MUSIC]