Let me start out by giving you

a quick 10-minute introduction to the Essentials of Networking.

Given the fact that we have limited time,

I would concentrate on delivering you

the essentials that you need for understanding each of the topics.

Now, what we cover in this particular module will require

at least a rudimentary understanding of how computer networking

works before we understand why we need to use HTTP,

why we communicate with a server,

what is the reason for the delay when you are talking to a server and so on.

And also, the various protocols that you

need to be aware of before you can even communicate with a server.

So, keeping all this in mind,

a 10-minute quick introduction to the Essentials of Networking.

We begin to realize that web applications are no longer stand-alone.

They always have a quote unquote Cloud backend supporting your web application.

Now these days, everything is on the Cloud.

Pretty soon you will be on the Cloud too,

at least on cloud nine with a silver lining.

But, given that we need

a server side support for our angular application to work correctly,

there would you host the server.

And these days, hosting the server is very

easily done by using one of the cloud-based infrastructure services,

things like Amazon Web Services or Heroku or Digital

Ocean or many others that provide cloud-based server support.

So, what exactly is available on the server side?

You typically have a server frontend that is talking to your angular application,

so that is the server logic and behind the scenes the server logic is communicating with

a persistent storage like a database where your data is stored and retrieved from.

When you enter the networking world,

you'll be pretty soon bombarded with 304 little acronyms,

things that you thought you knew what they were from normal English or they have

an entirely different meaning or

purpose when you encounter them in that networking world.

So let's examine a few of them.

So in the networking world you will hear people talking over HTTP protocol.

The protocol that is used for communicating between the client and the server.

This is an application layer protocol that we will briefly

talk about a little more in the rest of this lecture.

The HTTP protocol for it to work needs a URL to be supplied to it,

the Uniform Resource Locator.

So this is a string of characters separated by slashes,

with an HTTP colon or an HTTPS colon attached in front of it.

And I'm sure if you have used the World Wide Web,

you are pretty familiar with what the URLs look like.

Now in addition, you would hear people talking about JSON,

not your friend Jason but JavaScript Object Notation.

So the JavaScript Object Notation is one way of encoding data that

is being shipped from the server side to the client side or vice versa.

And also you will hear people talking about XML yet another way of

encoding data while it is in transit shipment between the client and server side.

Now, also you will hear people talking about higher level protocols called SOAP,

not the kind that you take a shower with but SOAP as a protocol that

allows communication between distribution entities within their network.

And also, you will hear people talking about REST,

not something that you get too much going through this particular course,

REST or Representational State Transfer.

I will have a shorter lecture

specifically devoted to REST a little bit later in this module.

And in the HTTP world,

you would hear people talking about GET, PUT,

POST, and DELETE and you'd be wondering,

what do they all mean?

Let's learn a little bit about these in

this lecture and also the lecture on REST that you will see a little bit later.

One important thing that you need to understand when you are

communicating with a server is that the client server communication

causes unexpected amount of delays or indeterminate amount of delay

while the data is being either fetched or uploaded to the server from the client site.

So which means that within your client site application,

you need to keep the user informed about the fact that

something is going on behind the scenes and be

able to handle the delays and

possibly not being able to obtain the data from the server side.

It is quite possible that when you try to connect to a server,

the connection of the server may fail,

the server may return incorrect data or may cause an error in communication.

All these have to be handled on your client side appropriately so that your application

will still keep functioning even in the presence of these problems.

Jumping into the most popular application layer protocol

used for communicating between the client and the server,

the Hypertext Transfer Protocol.

But this is a client server communication protocol.

Now that may or may not make much sense to you

unless you have sufficient background in networking,

but this is a protocol that is used for encoding the messages that you

exchanged between your client application which is

an angular application in this case and a server side.

So this HTTP protocol allow you to

retrieve hypertext-based documents from the server side,

increasingly the information being downloaded from the server side is

encoded in one of the standard encoding formats like JSON or XML.

And in order to be able to talk to a server,

you have the support from various HTTP actions or what we refer to as HTTP verbs,

the HEAD, GET, POST,

PUT, DELETE, TRACE, OPTIONS, and CONNECT.

We will see in particular the GET, PUT, POST,

and DELETE verbs in more detail when we examine the REST API protocol a little bit later.

How does the HTTP protocol work?

In the HTTP protocol,

you are sending GET request from your client application to the server.

And this is encoded in the form of an HTTP request message.

The request message typically carries a URL in

the request message indicating what is it that you want the server side to send you.

And this is typically a GET message if you want

data to be downloaded from the server side.

You will also specify which particular server you are communicating with.

When the server receives your request,

the server will retrieve the data from its data storage,

typically a database on the server side,

and then package this data in

an appropriate format and send the data back to you on your client side.

If you are obtaining standard HTML, CSS,

and JavaScript code from the server side,

then your browser is able to render this.

But with applications like Angular,

you are primarily connecting to the server and then

retrieving data in the form of either JSON or XML most of the time.

Except for the initial download of all the resources that are required

for your Angular application to be executed within your browser.

So as we saw earlier,

the HTTP application requires messages to be sent between the client and the server.

A request message is typically sent from the client to the server and

the request message consists of a request line plus a bunch of headers,

where you supply additional information to qualify the request.

We will see the use of various headers and settings in

the headers as we go through some of the exercises in this particular module.

The request line and headers are separated from the body of

the request message by one blank line.

The body of the message may contain additional data

especially if your client is sending data over to the server side.

For example when you submit a form,

the information within the form is encoded into

a JSON format and then sent over to the server side from the client side.

So that will be done using either a POST or a PUT message.

Looking at the little more details of the HTTP request message,

the typical request message in

the request line will contain the method which is either GET, PUT, POST,

DELETE or some of the other verbs that you have seen earlier,

and then followed by the URL and the version of

the HTTP protocol that you're using for communicating from the client to the server side.

The header field usually contains a header field name,

colon, and the value for that header field.

And the body contents, as I mentioned,

could be encoded in either JSON or XML format.

Here is an example of

a typical HTTP request message that may be sent to the server from the client.

So in this particular request message,

we are asking the server to retain the index.html page from

the server side to the client side so that it

can be rendered in the browser on the client side.

A request like this would typically have an empty body in the request message.

Most of the information will be encoded in

the request line plus the headers of the request message.

When the client sends the request to the server.

The server will process the request and then send back a reply to the client side.

The reply message is organized into again, three parts,

a status line where some information about how

the request has been processed and what is being sent back to the client is stored,

the headers will contain additional details of what is

contained in the response message and then followed by a blank line,

and then the actual body of the message.

An example of what would be typically contained in an HTTP response message,

in this case, this response message is coming back with a 200,

which is a status code of the message.

If you see a 200 in the request line as a status code,

it means that your request was successful and the server is able to

return the data that you have requested from the server side.

And then the header will contain additional directions to

the client side including information about

how the actual body of the message is encoded.

Then the body may contain,

if you have requested the index.html page,

the body of the message will contain the HTML code for

the index.html page as you see in this example here.

One of the pieces of information in the status line that I refer to as the status code.

If the server is able to process your request correctly,

it will send back a reply with a status code of 200,

meaning everything is okay on the server side and

the server side is returning the data correctly.

If the server is unable to process the request for whatever reason,

then that information will be encoded in

the status code in the status line of the reply message.

The various status codes typically that you will encounter when you

receive a reply from the server side include a 201,

which means that when you try to create

an object on the server side it has been successfully created,

or a 301 which means that whatever you are requesting has moved permanently

to a new location and the URL of

the new location of that resource will be returned to your client side.

400s and 500s typically indicate that there is some problem on the server side.

404 is something that you often encounter when

you request for something that doesn't exist on the server side.

Similarly, 500 means that the server is just giving up,

it is unable to process your request and then sends back an internal server error.

These are two common error codes that you will encounter.

The remaining ones have specific meaning as listed in this table here.

There are more than the status codes that I gave you in this table,

but these are some of the most common status codes that you will

encounter in a reply message coming from the server side.

Another point that I mentioned is the fact that the server may encode

the data in a specific format like XML or Extended Markup Language or JSON,

the JavaScript Object Notation format.

Now typically, in this particular course,

we will be dealing with data that is encoded mainly in JSON.

Most client side applications

including mobile applications these days typically communicate with

the server and the data exchange format is JSON by default in most cases.

That is the reason I will spend a few minutes explaining to you about JSON.

The JavaScript Object Notation or JSON is a lightweight data interchange format.

The reason the JSON data format is specifically of

interest to us in this course is because the JavaScript Object Notation,

as the name implies,

very easily maps into a JavaScript object that you use with any JavaScript code.

So converting a JavaScript object

into JSON notation and vice versa is very straightforward.

The JSON notation is what we call as a

self describing and very easy to understand notation.

In the JavaScript Object Notation format,

the data is structured in a very clean, specified manner.

This is structured as a collection of name, value pairs,

and this is structured as an ordered list of values.

You can see an example of this on the right hand side here.

We have actually used this JSON data within our angular application already earlier.

So, now you see why the data is structured that way.

And you also realize that it is very easy to be able to deal with

this data within your JavaScript or your TypeScript code in your Angular application.

With this, I complete a quick overview of networking essentials.

Networking Essentials

Server-side Development with NodeJS, Express and MongoDB

Conoce a los instructores