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
245 个评分
The Hong Kong University of Science and Technology
245 个评分
课程 5（共 5 门，Specialization Full Stack Web and Multiplatform Mobile App Development）
从本节课中
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 Angular application and how do we make use of this to communicate with a 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 on 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.
And typically, SOAP is based on using XML as
the format for the messages being exchanged between the two endpoints.
A 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 the 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 thesis
that actually produce 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 and 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.
And 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 what 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 lies 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 in 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're asking for the server to update an existing resource.
And if you issue a DELETE request,
you are asking for the server to delete that 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 constrained 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 or 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 a 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 this 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.
Like dishes/123, for example,
might mean dish number 123 in this case, and so on.
So, it is 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 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 that 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 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 a 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 that 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 confirmation 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 that 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.
The 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 tried to
delete a resource and if the resource exists, it will be deleted.
If you try to delete a non-existing resource,
it wont 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 modification to the resource on the server side.
POST input, 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.
And 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
the 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 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, every request that the client 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 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,
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.
