Back to our networking diagram.
So the HTTP request will include the URL we just talked about along with
other bits of information, such as what action we want to perform on the data,
information about the device, making a request, and more.
The whole request gets packaged up together.
It's like sticking a message in an envelope.
The HTTP request is like an envelope with a destination and a return address.
After the request is packaged, Android offers functionality to help a sender
message over the network to the correct web server.
We haven't officially defined the word network yet, but
you can think of it as a digital postal service.
A network is really just two or
more computers connected in some way that let's them communicate.
And when I say computer, I mean any computing device like a phone,
laptop or a server.
The internet is a large scale network consisting of many computers around
the world.
And we can use the HTTP protocol to route our request
from one computer to the other.
To communicate to a computer on a different location, we must establish
communication channel, also known as a network connection, across the internet.
Then we can exchange messages with the other computer.
In this diagram, we've represented USGS as a single computer, but
keep in mind that they have a lot of data.
So they probably have a whole group of computers who are responding to
requests.
A single computer wouldn't be able to handle requests from all over the world
for the US geological data.
At this point, I want to introduce you to some more
formal terminology that you'll often hear.
You can refer to the USGS computers that are providing data
as the USGS Web Server.
A web server is simply another computer or a group of computers on
a network running a program that responds to HTTP requests.
On the other hand, your phone can be referred to as the client.
The client requests the information from the server and
then displays the results to the user.
Often, many different clients would be connected to the same server, but
each client may display the data in different ways.
For example, a mobile client may show information that is more convenient to
viewing in a small mobile screen.
A web client on a desktop, for instance, might show more detailed information
taking full advantage of the larger screen size.
Each client sends out a request to the server.
When the web server receives the request, it may compose an HTML web page
to return to the sender for display, or it might return structured data
that we can use in an app we're building in a format such as JSON or XML.
Once the clients receive the response from the server,
they control how the data gets displayed to the users.
For example, a web browser can render a web page to the screen or
a mobile app can parse out the bits of data that it needs to show useful
information on the device screen.
In this lesson, we'll zoom in on major steps for the data exchange process.
First, we'll talk about how to form a proper HTTP request
based on the information we want and from where we want to get it.
Second, we'll send the request to the server, which will process it and
figure out a proper response to send back.
Third, we'll talk about how the client can process or parse this response and
convert it into a format that it understands.
Then lastly, we can update the UI in our app to show the results to the user.
Before we get into the details of networking, though,
there's one constraint on the Android device that we need to deal with first.