Explore
For Enterprise
Join for Free
Log In

Artes e Humanas
Negócios
Ciência da Computação
Ciência de Dados
Tecnologia da informação
da saúdesaúde
Matemática e Lógica
Desenvolvimento Pessoal
Ciência e Engenharia Física
Ciências Sociais
Línguas
Notas
Certificados

Explore todo o Coursera

Navegar
Pesquisar
For Enterprise
Entrar
Inscreva-se gratuitamente

Lesson 56: HTTP Basics

Loading...

HTML, CSS, e Javascript para desenvolvedores web

Universidade Johns Hopkins

4.8 (5,045 classificações) | 180K alunos inscritos

Curso 4 de 6 no Desenvolvimento Web com Ruby on RailsDesenvolvimento Web com Ruby on Rails Programa de cursos integrados

Do you realize that the only functionality of a web application that the user directly interacts with is through the web page? Implement it poorly and, to the user, the server-side becomes irrelevant! Today’s user expects a lot out of the web page: it has to load fast, expose the desired service, and be comfortable to view on all devices: from a desktop computers to tablets and mobile phones. In this course, we will learn the basic tools that every web page coder needs to know. We will start from the ground up by learning how to implement modern web pages with HTML and CSS. We will then advance to learning how to code our pages such that its components rearrange and resize themselves automatically based on the size of the user’s screen. You’ll be able to code up a web page that will be just as useful on a mobile phone as on a desktop computer. No “pinch and zoom” required! Last but certainly not least, we will get a thorough introduction to the most ubiquitous, popular, and incredibly powerful language of the web: Javascript. Using Javascript, you will be able to build a fully functional web application that utilizes Ajax to expose server-side functionality and data to the end user.

Visualizar o programa do curso

Habilidades que você aprenderá

Html, JavaScript, Css Frameworks, Cascading Style Sheets (CCS)

Avaliações

4.8 (5,045 classificações)

5 stars
4,438 ratings
4 stars
513 ratings
3 stars
48 ratings
2 stars
23 ratings
1 star
23 ratings

JH

Jun 01, 2019

Very interesting and well presented. It's difficult to address all the different experience levels so some points were (to me) a bit laboured, but overall a useful, informative and enjoyable course.

DQ

Feb 20, 2017

I learned very much in this course. I enjoyed each moment studied the content. The teaching methodology is wonderful and teacher is so nice. In general, this course is excellent and I recommend it.

Na lição

Using Javascript to Build Web Applications

In this module, we are going to take all those newly learned Javascript language skills and learn how to utilize them within the context of a web page. We’ll start by learning how to properly manipulate the web page components using the Javascript Document Object Model API. We will then move on to learning one of the most popular ways of serving up data to a web site - Ajax. We'll learn about the protocol that the language of the web speaks in (HTTP), how to set up and handle Ajax requests and responses, as well as how to process JSON data. We'll finish the module by connecting our restaurant web site from Module 3 to a real backend service that will allow us to pull the data for the restaurant menu dynamically from the server without having to reload the entire page.

Lesson 56: HTTP Basics12:50

Lesson 57, Part 1: Ajax Basics5:43

Lesson 57, Part 2: Ajax Basics13:11

Lesson 57, Part 3: Ajax Basics6:45

Lecture 58: Processing JSON9:08

Ministrado por

Yaakov Chaikin
Adjunct Professor, Graduate Computer Science

Transcrição

[SOUND] >> Before

we launch into discussion about AJAX, which is essentially a client-server

communication technique, let's talk about the language in which the client,

that is the browser, communicates with the server.

And the language that they use, otherwise known as protocol, is HTTP.

So let's talk about some HTTP basics.

Number one is what is HTTP?

Well HTTP stands for HyperText Transfer Protocol, HTTP.

And it's based on a request response stateless protocol.

And stateless in this context means that when the server responds

to a request from a browser,

that response does not depend on any previous requests that the browser made.

In fact, as far as the actual language in which the client, the browser and

the server communicate, the server has no idea whether or

not the client or the browser has requested anything from it before.

Now, obviously, in the real world, you need to be able to know that if I click

to buy a book two minutes ago, that when I go to my shopping cart and

want to check out, that I'm the same person who clicked to buy the book.

And it's a little bit outside of the scope of this course to explain how that works,

but the protocol itself, the HTTP protocol is stateless.

There's nothing inherently in it that remembers that you are the same person who

requested or made that request between the browser and

the server a couple of minutes ago.

So the way the client-server communication works is as follows.

The client, the browser usually, opens the connection to the server.

Then the client sends an HTTP request for a particular resource.

And then the server responds with an HTTP response to the client,

usually with a resource that the client requested, but

sometimes the resource is not found or some other error occurs.

And then the client,

that is again the browser usually, closes the connection to the server.

Now before we speak about the actual communication language, the HTTP protocol,

for a little bit, let's talk about how to identify a resource on the web.

And the way we talk about it,

we have three terms that we need to understand that are kind of thrown around.

And it's a good idea to understand what they mean.

The first one is Uniform Resource Name, otherwise known as URN.

What a URN is, is a way to uniquely identify a resource or

a name of a resource.

The thing though about URNs is they do not tell us how to get that resource.

And URNs are very commonly used by organizations and

institutions who want to standardize to maintain some uniqueness of a particular

resource within that organization.

So, for example, if Coursera wanted to maintain unique names for

each course that they have, they could make my course or

this course you're taking and could generate a string

that says HTML/CSS/Javascript/Web Developers/Yaakov/Chaikin,

with the slashes in between, and it will probably uniquely identify courses or

this course within all the other number of courses that they have on the platform.

It will not, obviously, uniquely identify my course all over the world, but

it might uniquely identify it within the Coursera platform.

Another term is URI, and URI stands for Uniform Resource Identifier.

And what that does is uniquely identifies a resource or a location of a resource.

But even though it identifies uniquely the location of resource,

it still does not necessarily tell us how to get to that resource.

And the reason it doesn't is because within a URI,

the context is usually missing.

It's very similar to URN except the URI is much more directory

type of structure looking thing.

So, for example, a URI might be /official_web_site/index.html.

While if I'm sitting at coursera.org,

this will mean a unique URL put together with the coursera.org.

But if you just give me the URI itself, it doesn't really tell me where to get it.

And if you just come over to me and

give me this URI /official_web_site/index.html, I will not

be able to get that resource because I won't know where to go to get it.

Once you take me to where to get it, if you take me to coursera.org, and

I start from the root of coursera.org, and I could start searching

/official_web_site/index.html, then I'm able to get it.

But URI by itself doesn't necessarily tell us how to get that resource.

The last final term is URL, and that stands for Uniform Resource Locator.

And this is something that's obviously thrown around on the web

all over the place.

When you ask somebody for a website address, it's a URL,

it's a Uniform Resource Locator.

And URL is a form of URI that provides the information on how to get that resource.

So, for example, if you tell me that it's

http://www.mysite.com/official_web_site/i- ndex.html,

I know exactly where to get it because mysite.com only exists in one place.

So I know where to go to get that resource.

So let's take a look at an HTTP request structure, in other words,

the actual language that the browser communicates with the server.

And this is an example of a GET request.

So this request starts with the word GET, and it's almost like a command.

I want to get some particular resource.

And that command is called a method.

And there's many methods and we're going to talk about a couple of them.

Then follows the URI string.

So this command has particular parameters you have to pass it.

So it starts with a GET, and then you pass it a URI string.

And then you pass it a query string, which is not a requirement, but

a lot of times you do see that.

And a query string is nothing more than a name value pair separated by ampersand.

So, for example, in the orange box,

you can see that question mark, which is something that starts the query string.

And you see first=Yaakov&last=Chaikin.

So those are two name value pair parameters.

And the last part of this command is HTTP/1.1, and

a long time ago, already at this point was HTTP/1.0,

it's the HTTP version, the version of our language.

So this is the command that the browser issues

to get at a particular resource on a website.

I'm sure, looking at it,

you could start seeing that there's something strange about this command.

Where is the website name?

How do I know it's a URI, it's not a URL?

The reason it's a URI, not a URL, is very simple.

This command is only issued once the browser actually connects to the server.

So we're already connected to coursera.org or to mysite.org.

And now that we've connected and established a connection to that

particular website, now we are asking for a URI within the context of that website.

And the way we ask for it is using a particular language, and

that language is called the protocol.

It's the HTTP protocol.

A good analogy would be, if you and

I both speak English, that's our language, that's our protocol.

When I say hello, you say hello back.

However, it's no use for me to stare at my phone and

keep saying hello to you if I've never even dialed your number, right?

The first I need to do is I need to dial your number, connect,

our phones need to connect together, and once the connection is established,

I could then ask you and say hello, and ask you questions.

Before then, I really can't do anything.

Well, very similar to here.

The browser first has to make a connection to the server.

And once it makes a connection, it starts the HTTP protocol,

starts the language of communication between the browser and the server.

So what you see in front of you in the slide now is a GET command,

otherwise known as a GET request.

And it's named after the method, or

the command, that is issued as the beginning of this line.

Now there are a number of these methods, and let's go ahead and take a look

at a couple of them that, at least for us, is going to be pretty important.

One of them is, again, the GET command or the GET method.

And what that does is it says,

I want to retrieve the resource from the particular location.

And the way you pass the data using that method

is you pass it to the server as part of the URI.

As you remember, we had the query string, well, that's how you pass the data.

And the data is not so much to be stored on the server as much as really a way for

us to tell the server and identify a particular resource, or

maybe filter a particular resource, the data from that particular resource.

So we need to pass the data to the server in order to get the data back.

It's not really for the server to store it, necessarily.

The other command, or the other method, HTTP method, is POST.

And this method sends the data to the server in order to be processed.

And the data that you sent to the server is sent in the message body.

Now the server may still respond, and most of the time does,

respond with some sort of response, maybe an HTML page, maybe some sort of data.

But that data is more viewed as a status or kind of a confirmation that

the data that you sent to the server was in fact processed, whatever that means.

Stored or some other side effect happened because of it, but

it's an indication that it was processed.

Now, there's many more methods that we're not covering here,

but these are good enough just to get an idea of the actual protocol.

So when we talk about POST request and the data being sent as part of the message,

let's go ahead and quickly visualize what that looks like.

So this is a typical POST request, and

you could see there's a POST /index.html, but there's no query string.

The query string or

the data that we're passing comes as part of the body of the message.

So there's a few parts here that actually exist on pretty much every POST request,

which is the first line, the POST request itself, followed by some request headers.

In this example, Accept-Charset is telling the server that our

browser knows how to process utf-8 character set.

And, after that, we have the message body.

This is where the data is being passed to the server.

So this is the POST request.

Let's take a quick look as to what an HTTP response structure is like.

Well, it starts with just a response status line.

And the response status line has three components.

The first one is the HTTP version.

So the server spits back out the version of HTTP it's communicating.

The second is the response status code.

And the third is the English phrase describing that status code.

And all three parts are separated by a single space.

So a typical HTTP response may look something like this.

It will start with HTTP/1.1 200 OK.

It will follow by some HTTP response headers,

in this case, it will tell you what the date of this document is.

It will tell you the content type, in this case, it's text in HTML.

And then the body of the message or the body of the response will be HTML.

Now the message body of the response need not be HTML.

It can be, for example, plain text, XML, or

JSON, something we haven't really talked about yet.

So let me show you some common response status code.

One of them is 200 OK.

And that basically means that the server is saying, okay, I got your request,

and here's the content you requested.

Another one is 404 Not Found.

In this case,

the server says, I just can't find the resource that you requested.

403 Forbidden, and that means that, for whatever reason,

the server thinks that the client, your browser, is unauthenticated and

tries to access a secure resource that requires some sort of username and

password or a certificate or something like that.

And another one, pretty common, is 500 Internal Server Error, and

usually that happens when some error was raised on the server and

was unhandled on the server and it kind of spilled over.

And now, you as the user probably in the browser are seeing 500 Internal Error.

So, in summary, it doesn't take a rocket scientist to understand that if you're

going to be doing client-server communication,

you need to understand at least the very basics of HTTP protocol.

Now remember, the GET method sends the data to the server as part of the URL or

part of the URI.

That's going to be important for us as we move forward.

And the POST method sends the data as part of the message body.

And some common response codes are 200, that's fine, the data is coming,

404, it's not found, 500, there's some internal server error.

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play

Coursera
Sobre
Liderança
Carreiras
Lista de cursos
Certificados
Certificados MasterTrack™
Notas
For Enterprise
For Government

Comunidade
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

Mais
Termos
Privacidade
Ajuda
Acessibilidade
Imprensa
Contato
Diretório
Afiliados