One - the web server sends back an HTTP Response code to give us a message about what happened with the request we sent.

Two - if the request was successful, we receive and load the content of the response.

HTTP response Codes

1xx - Informational

2xx - Success

3xx - Redirection

4xx - Client Error

5xx - Server Error

The HTTP response codes the server sends back fall within these five categories.

The 100 level responses are information indicating that the request was received and the process is underway.

The 200 level responses are information indicating that the request was received, understood, accepted and processed successfully.

The 300 level responses are information regarding how the client must take additional action to complete the request.

The 400 level responses are information regarding how the client made an error in the request that was sent to the server.

The 500 level responses are information regarding how the server failed to fulfill an apparently valid request.

HTTP Response Codes worth knowing

200 - OK, successful HTTP Request

202 - Request accepted, processing not completed

204 - Request good, not content returned.

301 - Requested content has been permanently moved

400 - Bad request

401 - Authentication failed, not authorized

403 - Valid request, server refuses to respond

404 - Content not found

500 - Server encountered an error

503 - Server service unavailable

These are common responses worth keeping in the back of your mind.

As you program or use the internet, they are the most commonly encountered server responses that you shall see.

So going back to the Load step, the most common response here will be the 200 one telling us that the HTTP request was successful.

This means that the data sent back will be exactly what we requested and it is ready for us to use.

What we then do with this data is up to us.

For the most part, since these videos have been about doing data visualization with D3, it means we will be visualizing the data that was returned.

Next, let's talk about data in static versus dynamic web pages.

Thinking About Data In Static And Dynamic Web Pages

Data Types

Text - text/plain

JSON - application/json

XML - application/xml

HTML - text/html

CSV - text/csv

TSV - text/tsv

These are the six main types of data mime types that we deal with when working with D3.

They should be self-explanatory.

The CSV stands for comma separated values.

The TSV stands for tab separated values.

Static Data vs Dynamic Data

Generated Once vs Generated Multiple Times

Same when visited more than once?

When we think about whether data is static or dynamic, we can think about it in two different ways.

The normal way is to think about whether the data is generated once or whether it is generated more than once.

If it is generated once, then it is static data.

If it is generated multiple times, then it is dynamic data.

We can also think about it in terms of web URL / URI terms.

If we visit a URL that points to and returns a specific data set, we would say the data is static if regardless of when we visit the URL, the data set returned is the same.

If we visit a URL that points to and returns a specific data set, we would say the data is dynamic if regardless of when we visit the URL the data set returned changes.

Why is it worth thinking about it the second way?

It is worth thinking about it the second way, the URL way, because we can get static data sets of dynamic data generation processes.

For instance, we can argue that weather is dynamic and not static.

Yet, we can get a static data set of the temperature and humidity of several locations from January 1st 2013.

So from now on, when we talk about static or dynamic data, we will be talking about data in the sense of whether the web address of a data set returns the same or different data set from the last request to that specific address.

Data Types + Static / Dynamic Data

Static / Dynamic Text

Static / Dynamic JSON

Static / Dynamic XML

Static / Dynamic HTML

Static / Dynamic CSV

Static / Dynamic TSV

Given that we can have different data type files and we can have either static or dynamic data, we can have different combinations of data types and files.

Whether they are coming from a data base or being written to a file system that is able to be reached by URL, we can have all the different types of files.

Knowing what type of data we are dealing with now and what type of data we are going to be dealing with in the future is a big part of visualizing the data.

In addition to what type of data visualization we make, it also dictates how we load the data and what types of web pages we create.

Static vs Dynamic Web Page

The same way we can think of static and dynamic data, we can think of web pages in the same way.

If every time we load a web page it has the exact same content, then we can think of it as a static web page.

If at least some of the time that we load a web page it has different content then we can think of it as a dynamic web page.

If we then think about what type of data drives a web page to be static or dynamic, we can come to a pretty clear conclusion.

static data => static web page
dynamic data => dynamic web page

A static data set loaded into a web page would lead to a static web page.

The data does not change so the web page visualizing the data set does not change.

A dynamic data set loaded into a web page would lead to a dynamic web page.

Loading static data
- once and done

If we then think about how we load static data to the web page, we realize that we only have to do it once.

Since the data set will be the same regardless of when we access the resource through a URL, we only have to load it once and then we are done.

We can then visualize it or render it however we want.

Even though the data set is static, we have several things to think about...

We have to think about the size of the data set.

We have to think about what part of the static data set we will be using.

We also have to think about how the data set is being loaded into the client.

Loading dynamic data
- Rate of change matters
- Size of data matters

If we then think about how we load dynamic data to the web page, things become more complicated.

This is because we now have to think more carefully about how we treat the data that we receive from the server.

First, we have to figure out how frequently the dynamic data is changing.

Then we have to figure out how frequently we want to show this change on the web page.

Then we have to think about whether the data set is changing in size.

Then we have to think about how long the data is valid.

Then we have to think about whether it makes sense to cache the data in the web browser.

and just like with the static data set, we also have to think about The size of the data set.

What part of the dynamic data set we will be using.

As well as how the data set is being loaded or will be loaded into the client.

All of these questions lead us to thinking about how to load and use the right data for each type of page and data set.

Loading And Using Data In Static And Dynamic Web Pages

Loading Data Questions
- Data Size?

When we start thinking about our data and how we are going to use it, the most important question we need to ask is how big is the data set.

The rest of the questions we asked at the end of the previous section will be affected by this one question.

Depending on the answers to the size question, the way the data is loaded and used will cause the code we write on the server and on the client to be vastly different.

Sometimes more simple and other times much more complicated.

Loading Data Questions
- Data Size?
- How is data loaded?
- What is the frequency of change?

The size of the data set we are serving matters for four reasons.

Three which concern us and one which concerns our audience.

The three reasons which concern us are hosting, bandwidth and server related.

The bigger the data set we are hosting, the higher our costs to have the data readily available for serving.

Though the prices are minute, if the data set is accessed very frequently, the costs can add up very quickly.

The bigger the data set we are hosting, the higher our bandwidth costs to have the data being server from our server.

The bigger the data set we are transmitting, the more work the server will have to do in order to keep the connection open and to serve the data.

Which are important things to think about.

However, the most important thing to think about is our audience.

The bigger the file size the longer it will take to load in their web browser.

The slower the website the more likely our audience will leave.

So it is crucially important to think about how to minimize the wait time for the web browser to load the data.

If the data size is very small, then it makes sense to load it as part of the web page being loaded.

If the data size is bigger than very small, then it makes sense to load it after the rest of the web page elements have been loaded and constructed.

If the data size is big or larger, then we have to start thinking about splitting the data into separate parts that we load either sequentially or as needed.

The other question that comes up with dynamic data is how frequently the data set is changing.

Within this question, we have to start thinking about whether we are going to cache the data.

How often the data is being refreshed on the server side and how to implement it.

How often we need / want the data to be refreshed on the client side and how to implement that.

We also have to think about how to implement code that makes sure that stale data generates an alert so the audience on the client knows that they are looking at stale / old data.

Just like the data loading questions, depending on the frequency of change, these questions will lead to very different strategies on both the server side as well as the client side.

One commonality that all of the different questions contain is that they all have to do with requesting, receiving and processing data asynchronously.

[ Image: AJAX Web Application Model ]

And to do asynchronous requests, we use the AJAX Technology.

Because JavaSCript is single-threaded, having the ability to do AJAX calls makes it less susceptible to a slow down in the program.

With AJAX, data is retrieved using XMLHttpRequest objects.

JavaScript and the XMLHttpRequest objects provide a method for exchanging data asynchronously between browser and server to avoid full page reloads.

XMLHttpRequest (xhr)

GET

POST

HEAD

PUT

DELETE

OPTIONS

XMLHttpRequest or XHR for short, is an API available in web browser scripting languages like JavaScript.

It is used to send HTTP and/or HTTPS requests directly to a web server and load the server response directly back into the script.

The data received from the server can be JSON, XML, HTML and/or plain text.

The methods that it uses are the same as HTTP.

The basics of the XHR object is that once created, the Object will go through a series of states of opening a connecting, sending information, ready state when the HTTP content begins loading and the ready state for when the HTTP content has finished loading.

Only after the content has finished loading, will the asynchronous JavaScript code proceed.

D3 has Type Specific XHR functionality to load in data into the browser from a server.