Let me start out by giving you a quick 10-minute introduction to the essentials of networking. The more I teach English, the more I realize that just to use their prettiest features of angular you need to have an understanding of so many different connected FINs before you can even understand what you're doing with angular. By the moment you start chasing each one of these FINs, they will become entire courses on their own and pretty soon, I'll end up teaching their entire computer science curriculum to you. But given the fact that we have limited time, I will concentrate in 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 is that 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 back-end supporting your web application. Now, these days everything is on the Cloud. Pretty soon you'll be on the Cloud too, at least on cloud nine with a silver lining. But given that we need a Silverside 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 that you can leverage for providing server support for your angular application. So, on the server side, what exactly is available on the server side? You typically have a server front-end 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 the networking world. So, let's examine a few of them. So, in the networking world you'll 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 in each TTP colon, on an https: attached in front of it. And I'm sure if you are used the world wide web, you are pretty familiar with what the URLs look like. Now, in addition, you will hear people talking about JSON, not to 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 site. Now, and 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 the network. And also, you will hear people talking about REST, not something that you get too much going through this particular course. REST or a 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 will 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 this 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 side. So, which means that within your client-server 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 tried to connect to a server, the connection to 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 be 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 exchange between your client application, which is an angular application in this case, and a server side. So, this HTTP protocol allows 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 a request from your client application to the server and this is encoded on 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 with the server side to send to you and this is typically a GET message if you want to data to be downloaded from the server site. And 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 four back, 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. Back 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 the 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 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 clients are sending data over to the server side. For example, when you submit a form, the information within the form is encoded to 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 a 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, PAUSE, 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 and index.hmtl 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 with 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 here, 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 start HTML page as you see in this example here. One of the pieces of information in the status line that I refer to as that status code. If the server is able to process your request correctly, it will send back a reply with a state score of 200, meaning everything is ok 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 that 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 that you are on the new location of that resource will be returned to your client side. 400s and 500s typically indicate that there are some problems on the server side. A 404 is something that you often encounter when you request for something that doesn't exist on the server side. Similarly, a 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'll 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 eXtensible Markup Language or JSON, the JavaScript Object Notation for that. Now, typically in this particular course we will be dealing with data that is encoded mainly in JSON. Most applications, 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 that 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 of javascript codes. So, converting a javascript object into JSON notation, and vice versa, is very straightforward. That JSON notation is a, 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 with 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 audio, typescript is caught in your angular application. With this I complete a quick overview of networking essentials. We will now move on to and exercise where we will set up a rudimentary server that was serve up some data that we can connect to from our angular application and then exchange data with a server. Now, we will develop a full fledged server in one of the later courses, the Node code JS and server side development course that would come as a last course in this specialization.
