Video 2: HTTP Request

Loading...

來自 University of New Mexico 的課程

Web Application Development: Basic Concepts

113 個評分

University of New Mexico

Web Application Development: Basic Concepts

113 個評分

This is the first course in a Coursera Specialization track involving Web Application Architectures. This course will give you the basic background, terminology and fundamental concepts that you need to understand in order to build modern full stack web applications. A full stack web developer is familiar with each "layer" of the software technologies involved in a web application, including data modeling and database technologies, the web server environment and middleware components, network protocols, the user interface and basic visual design and user interaction concepts. In this course we will learn by doing. We will start by learning the major components of web application architectures, along with the fundamental design patterns and philosophies that are used to organize them. You will build and continually refine a fully functional full-stack web application as we progress through the modules in this course. Along the way you will be exposed to agile software development practices, numerous tools that software engineers are expected to know how to use, and a modern web application development framework. This course is also available in Spanish. To join the Spanish version, visit this page: https://www.coursera.org/learn/apliweb.

從本節課中

Module #4 - Middleware

Middleware is an abstraction layer that hides details about hardware devices and other lower-level software services from an application. Middleware services implement common low-level functions, such as communication with the operating system, application servers, database servers, etc., so that application developers do not need to concern themselves with these details, and can instead focus on the application functionality they are trying to provide. In a web application, these services generally make use of the HTTP protocol, and in a web application framework, the MVC design pattern can be thought of as being implemented over the middleware.

The HTTP Protocal - An Overview0:24

Video 1: HTTP Overview5:57

Video 2: HTTP Request7:27

Video 3: HTTP Response4:23

Video 4: HTTP Sessions and Cookies5:17

與講師見面

Greg Heileman
Professor and Associate Provost
Electrical and Computer Engineering
Manel Martínez-Ramón
Professor
Electrical and Computer Engineering

[MUSIC]

Now that we've seen how web sessions work,

let's take a more detailed look at the request side of the HTTP protocol.

Here are the specific pieces of an HTTP request.

It consists of three parts.

There's a Request line, a Header, and then a Message body.

We'll now consider each of these parts in turn.

Let's look at the Request Line.

It identifies the resource that's being requested and

the desired action, sometimes this is called request, verb or

method instead of action, that you'd like to apply to that resource.

The resource is identified by a Universal Resource Identifier, more specifically,

a Uniform Resource Locator, sometimes you'll hear this referred to as URL,

very common, is a specific type of a URI.

Now there are nine request types that can be specified and

I'm going to list each of them.

The first is a Head request.

This is the response that would be supplied to a GET request but

it doesn't include the body.

One of the most common requests is a GET request.

It simply returns a representation of the resource.

POST allows you to submit data, for example from an HTML form to the resource.

So the data is supplied in the body of the request, and the result may be

the creation of a new resource or it could involve updating an existing resource.

PUT.

This submits a representation of the resource to the server.

DELETE is the next one, this allows you to delete a resource.

TRACE echoes back a received response.

OPTIONS returns the HTTP methods that the server supports for

that specific resource.

CONNECT converts the request connection to a TCP/IP tunnel.

This is what's used to facilitate a TSL or

SSL encrypted communication to HTTPS.

And then finally PATCH allows you to apply a partial modification to a resource.

So a couple of things about these types of requests.

The HEAD, GET, OPTIONS and TRACE are referred to as safe methods.

What this means is that they do not produce side effects on the server.

So if you do a GET request, for example, it'll get the resource but

it does not change it on the server side.

So no side effects.

If a GET method is implemented in a safe way, then think about this,

a browser can make an arbitrary number of GET requests without modifying the state

of a web application.

So these requests therefore can be cached and

this allows you to improve performance.

The POST, PUT, and DELETE methods, they can cause side effects.

They're changing the resource.

So therefore they're not called safe methods.

The PUT and DELETE methods, what you'd like is for them to be idempotent.

What this means, if you do multiple identical requests,

they should have the same effect as a single request.

So if you put a resource multiple times, it should continue to override it.

If you delete a resource multiple times, it should be deleted the first time.

And after that it shouldn't change what's on the server side.

So the safe methods, if you think about, since they

don't change the state of the server, are therefore by definition also idempotent.

On the client side, let's talk about now the header.

Again, we talked about there's a request line, a header, and then a message body,

so this is the second piece.

The HTTP message header is the primary part of the request.

Here's a typical syntax.

There's a field_name: and then the value for that field.

Here's an example,

you might see something the header that looks like Accept: text/plain.

This is saying that the browser can accept just plain text

that the language, this one is saying that the accepted language is English.

The headers can be any application-specific string, but

they are a core set that was defined by the IETF that are commonly used.

An HTTP message header must be separated from the message body by a blank line.

So after the header, blank line, and then here comes the third part, the body.

So the message body is optional.

Doesn't have to appear in a request.

It's typically included if there's user-entered data that needs to be

uploaded to the server side.

If an HTTP request includes a body,

there are usually header fields that describe what is up in the body.

So, for example, you might see something like Content-Type

is text/html or the Content-Length is 3495 bytes.

So these things are describing the body itself.

So these are the three parts of the request,

the request line, the header, and then the message body.

To make this a little bit more concrete, let me pull up a website.

So here's The New York Times, and I'm going to use Chrome in this case,

and I'm going to select > View > Developer > Developer Tools.

So, again, all of the browsers have these.

So, here's the Developer Tools and I'm going to go ahead and hit reload,

so you can see the request that is made here.

And so here it is.

Let's select Network and then I can look at the requests, and a lot of stuff

happened here but the initial request was www.newyorktimes.com and

you'll see that it was a get request, it returned status 200.

We're going to talk about that in the next video, but

let's take a look at this request itself.

And I'm going to select the headers here.

And I want to see the actual request since that's what we're talking about.

I'm going to select View Source and if you look at this,

you'll see that it was a GET request and it used HTTP/1.1.

And here you see the headers.

So there's host, so the field name, and then the value,

Connection: keep-alive, Cache-Control, maximum age.

Accept: text, so this is saying what the browser can accept, so on and so forth.

So, everything here are headers.

There's no body to this and at the very end, you'll see a big, massive cookie.

So again, provide as a header.

So the header field and then the actual value is specified here.

So this is a GET request.

Let's go to our blog application and let's enter a new post.

And so I'm going to create a new post and

again I'm going to turn on the Developer Tools, so that we can see what happens.

And so we'll create a new post and let's just call it Test and Test.

We're going to create that post and let me look here, and

we'll see that this post is actually using the post method.

Again we can take a look at this and we can see that the Request Header

was of type POST and it used the route called POST.

This is what was added to the end of the URL here, then it was using HTTP/1.1.

You'll see in this case that the Header Field and down below there's

actually a body associated with this as well and it's in this Form Data.

So the form data contains the body.

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2018 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取