Take a moment to think about some of your favorite apps.
Chances are that many of your favorite apps
likely use the internet in some way to help deliver a great experience
whether it's useful or just for fun.
Being able to interact with data from the internet is
an important skill for Android developers
which is what you'll be doing in this pathway.
Before learning how to use the network
you'll need to first learn a bit more about what goes on behind the scenes
when your app sends and receives data over the internet.
With the kind of networking we'll be discussing
there are two different parts to consider, the client and the server.
A client can be a web browser or any other app on a device
that makes a request to a server.
The server, which you can think of as a computer
knows how to take the request and send a response back.
Here's an analogy that may be helpful.
You could think of the server like an ATM
and the client as a person trying to make a transaction.
The ATM machine is always available
and waiting for someone to interact with it.
The ATM handles each person's request differently
depending on what the request is.
For example, withdrawing money, depositing a check, and so on.
Going back to the client-server relationship
many different clients on devices like phones
desktops, laptops can send request to a single server
and it's the server's job to process each request
and send back the appropriate response to each client.
The client and the server use something called HTTP
which is the protocol to communicate with each other over the internet.
It includes specifics on how requests and responses should be formed
so the client and server can understand each other.
Let's look at how a web browser like Chrome can make a network request.
We can go to google.com and then type in Android as a search term.
This is what a simplified request would look like.
Each part of the request has a specific purpose
to help the server understand the client's request.
This request starts with an HTTP method.
This is a GET request
meaning that we're getting a resource from the server
which in this case is the web page with the search results.
The request also includes an endpoint, a host URL, and an HTTP version.
Furthermore, the request contains headers with additional information
about the client itself or about the data we're trying to fetch.
Don't worry about understanding all of the headers
and just focus on the key part of the request that we pointed out
like the GET method as well as the google.com host and endpoint.
Now let's take a moment to break down the request URL into its components.
You've likely seen website URLs all the time
such as in the address bar of your web browser.
The URL starts with the scheme followed by a colon
and two forward slashes, and it signifies what protocol to use.
In this case, the scheme is HTTPS
which stands for Hypertext Transfer Protocol Secure
as requests to this URL are secure.
Google.com is the host which corresponds to the domain
that the request is being sent to.
The specific resource that we're trying to access is specified with the path
with each segment separated by a slash.
This path or endpoint corresponds
to a specific task on the server side, such as getting search results.
In some cases, you can provide additional data after the path
in the form of parameters
such as specifying the search query in this example.
And that's how the request URL is composed.
You'll notice that the HTTP method in this request said GET.
HTTP has different possible methods to help the server understand
which type of operation the client is trying to perform.
A GET request specifies an endpoint
pointing to the exact resource that the client wants.
In addition, GET requests can also be more specific
by appending additional parameters to the URL.
As mentioned, these are added
after a question mark at the end of the path.
If there are multiple parameters, they are separated by an ampersand.
Here's an example.
In this YouTube video URL
the first parameter v is for the unique identifier of the video
and the second parameter t is the number of seconds
into the video where we should start playing from.
To create a new resource on the server, we can use the HTTP POST method.
Within the request, the client needs to include the new data
to be added to the server.
A POST request will typically include at least one additional header
specifying the type of data being posted.
For example, if it's text or some other media type.
The PUT operation replaces one piece of data in its entirety
with another piece of data.
You can think of it as updating a resource on the server.
Finally, the HTTP DELETE method represents a delete operation.
As you'd expect, you'd use a DELETE operation
to remove a specific piece of data from a server.
Using a social media app as an example
let's look at how the app would have requests
that use different HTTP methods.
When the user opens the app
it would be useful to fetch the list of all recent posts
so they can see what their friends posted.
That would be a GET request.
When the user wants to add a new post
send the new information in a HTTP POST request to the server.
When the user wants to modify an existing post
send an HTTP PUT request to the server with the updated post information.
And lastly, if the user wants to delete a previous post
send an HTTP DELETE request to the server and specify which post to delete.
As you can see, it's important to specify the HTTP method in requests
so the server knows what the client wants to be done.
All right, those are the key points to know for an HTTP request.
Let's move on to the response now.
When the server is done processing a request
an HTTP response is sent back.
That's how the web browser, for example, is able to show the results
for a search term.
Here's what the HTTP response for the search request could look like.
The response includes a number called a status code
as well as a corresponding status message.
Just like the request
the HTTP response contains various headers containing additional information
from the server like the content type
content encoding, timestamp information, and more.
Again, you don't have to understand all the different response headers
but here's an important one to note.
The content type specifies the media type of the response.
Is it text, an image, or something else?
In this case, the response contains an HTML document.
Knowing what type of data is in the response is important
because the client App needs to know how to parse
or make sense of the data in order to display it to the user.
After all the headers is the actual content
which is the HTML for this web page in our example
or the content could be an image if the request was for an image.
In the code that you'll take the response will be text data
in the JSON format, which you'll learn more about later.
We mentioned briefly that the response code contain
a 200 status code, but what does that mean?
There are many possible status codes
and they all fall into five basic categories.
Some are used more frequently than others
so let's just talk about the common ones that you may run into.
Statuses in the 200s
from 200 to 299 correspond to successful requests.
If the resource returned successfully to the client
the response will carry a status code of 200.
This is what we saw with our search request.
Statuses in the 400s represent client errors.
You may have seen the status code 404
if the client was a web browser and tried to access
a web page that doesn't exist.
Finally, status codes in the 500s represent server-side errors.
For example, a 500 error is returned if there was an internal server error.
Looking at the response status code can help you troubleshoot your app
if you're not getting the response you expect.
It can help point you in the direction of where to start looking for the problem
is it a client-side issue or a server-side issue?
That wraps up the high-level parts of an HTTP response and what they signify.
Let's move on to talk about the server for a bit.
In this pathway, you'll be building an app that makes network requests to a server.
That server has a REST architecture style.
A web service is considered RESTful if it abides by the following principles.
RESTful services implement client-server architecture
where there is a clear separation of concerns between the client and server.
The client makes the requests and the server sends back a response.
Resources on the server are identified by a URI or Uniform Resource Identifier.
Say, for example, the server stores a collection of photos
the server could expose a different URI for each photo
so you could retrieve each one individually.
A RESTful service also provides a uniform interface
meaning that you can manipulate the resources with CREATE, GET
UPDATE, and DELETE operations.
In REST, the server is also stateless
meaning that it does not need to remember the client's state between requests.
Each client request should contain all information needed
for the server to satisfy the request.
There's also other characteristics that make a web service RESTful
but we won't get into that for now.
Let's look at an example of a RESTful web service that stores messages.
This server exposes a set of URIs that a client can use to make requests.
When making a GET request with the first URI
you can get the list of all messages
or you could do a GET request for an individual message
by specifying the ID in the URI.
Another endpoint allows the user to search messages
for a certain query term.
And the last endpoint available on the server is
for creating a new message
and that requires an HTTP POST request with the contents of the new message.
By looking at what functionality the server exposes
you can build your client Android app accordingly.
As you move forward and build more complex apps
keep in mind what you've learned here about HTTP requests and responses.
And by completing the code that's in this pathway
you'll have a better idea of how to call similar RESTful web services
in your Android apps.
Good luck, and have fun.