This course deals with all things server-side. We base the entire course around the NodeJS platform. We start with a brief overview of the Web protocols: HTTP and HTTPS. We examine NodeJS and NodeJS modules: Express for building web servers. On the database side, we review basic CRUD operations, NoSQL databases, in particular MongoDB and Mongoose for accessing MongoDB from NodeJS. We examine the REST concepts and building a RESTful API. We touch upon authentication and security. Finally we review backend as a service (BaaS) approaches, including mobile BaaS, both open-source and commercial BaaS services. At the end of this course, you will be able to: - Demonstrate an understanding of server-side concepts, CRUD and REST - Build and configure a backend server using NodeJS framework - Build a RESTful API for the front-end to access backend services
Brief Representational State Transfer (REST)
Loading...
来自 The Hong Kong University of Science and Technology 的课程
Server-side Development with NodeJS, Express and MongoDB
398 个评分
The Hong Kong University of Science and Technology
398 个评分
课程 4（共 4 门，Specialization Full-Stack Web Development with React）
从本节课中
Introduction to Server-side Development
In this module you will be introduced to Node, Node modules and the Node HTTP server. You will learn about the Express framework and how to set up a REST API using Express.
与讲师见面
Jogesh K. MuppalaAssociate Professor
Department of Computer Science and Engineering
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 React 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 React application?
Let's talk about that a little bit more in this lesson.
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 at
the application layer level for web-based 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 endpoints communicate with each other.
Typically SOAP is based on using XML as
the format for the messages being exchanged between the two endpoints.
Representational 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 world.
Typically, client-server communication is
facilitated using REST where the server supports a REST API and
the client can then invoke the REST API endpoints in order
to obtain information or to upload information to the server.
Again, I have mentioned the word invoke the REST API endpoints,
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 theses
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 the 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).
Fourth, the format for data exchange is typically JSON
or XML or both can be supported using REST.
One of the motivations for Roy suggesting REST as a way for supporting web services is
that it captures all the things that are good about
the World Wide Web and that made the World 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 lives 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,
send the response to the request,
and the 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 World Wide Web.
Now, the HTTP protocol as we have seen earlier,
we will use all the various verbs that HTTP provides.
specifically, the GET, PUT,
POST and 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 resource.
If you do a POST request,
you're 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 are asking for the server to delete the resource
that is identified by the 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 refer to resources and these resources are
usually identified by their URLs and these are unconstrained.
Verbs are constraint and these specify the actions to be
done on the resources and representations 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, the information is abstracted in the form of a resource and the resource
is identified by specifying it by using a URL.
So, any information that can be encapsulated and be made available,
can be identified as a resource.
A piece of information like the 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 the server may send up to the client.
An example of how you name resources is illustrated here.
So we use URIs to identify the source.
A quick reading of these specification or the URIs here will
easily enable you to understand what we are referring to by using these URIs.
So, for example, something which ends with dishes/,
you automatically assume that this is referring to a collection of dishes.
But dishes/123 for example,
might mean dish number 123 in this case and so on.
So, it is very easy to save and 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 of the specification of this URI.
So, as you traverse the path,
you go from the more general to the more specific of the resource.
This directory structure enables you to identify the resources
that you use or provide from your server-side very easily.
The second part of the REST API are the verbs.
In particular, we are interested in the four verbs of HTTP the GET,
PUT, POST and DELETE.
In this case, these verbs will be mapped into actions that we
want to be performed on the resource, on the server-side.
A GET would mean you want to perform a read operation on the resource.
So, which means that a client sending a GET request is indicating to the server that it
wants to obtain a representation
of that resource from the server-side to the client-side.
A POST means that you want to create
a new resource and then you will specify the details of the resource
in the representation that is used for
specifying the resource and then send that information over to the server-side,
so that the server will create that resource on your behalf.
A PUT would be modification of resources and
a DELETE as you would expect is deletion of the resources.
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 the representation of
the resource to be returned to the client from the server-side.
So, when you issue a GET request to a REST API endpoint,
you are asking for either a collection of resources represented by
URI or a specific resource which is identified by the ID of that particular resource,
specified within the URL.
So, as you see in this example,
if you say, 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
an XML representation and that will 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.
When the server receives that request message,
the server creates that resource on the server-side and then returns
either a conformation or a error to indicate that the resource creation failed.
Similarly, a PUT operation is used 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 the 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.
A DELETE operation as you would expect deletes the existing resource.
Now, in this particular case,
of course a DELETE operation would be idempotent 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, DELETE is an example of an idempotent operation in this case.
Similarly, the GET operation is also an idempotent operation because it is
not making any modifications to the resource on the server-side.
POST and PUT of course are going to modify the resource on the server-side,
either create a new resource or modify an existing resource on the server-side.
Of course, the representations,
as I have been emphasizing,
the two common formats for representing is either JSON or 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 state because if the server needs to track the clients 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, every request that the client sends 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 that particular client.
So, it's the responsibility of the client to track its own state,
either in the form of using cookies or using a client-side database,
whatever means that is suitable.
Now, this approach where the client tracks its own state is
a lot more scalable because each individual client
will be responsible for tracking its own state.
This is where the client-side MVC setup helps us in this regard.
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.
