Until now, we’ve been working with this kind of standard picture of this little guy and his browser. Now, this used to be you, but now this is the user. You have upgraded to the other side of the picture where the servers are. So let’s get these boxes. We’ve seen these 100 times. Okay, and let’s add you over here. You are now the programmer. Congratulations, you are a web developer. We can talk about users and how much trouble they cause us. Now, in a normal web request, the user makes a request to the servers, and we respond with the response. No surprises there. Now, what we’re going to be talking about today is when your servers start making requests to other servers. So this is our website. It runs on these boxes. Let’s say we’re going to hit somebody else–Twitter, for example. They have their own servers. Their servers are probably on fire, because it’s Twitter. So we can have a web page that actually makes requests to Twitter. These are our computers talking to their computers. This happens all the time. They’re still communicating over HTTP, and Twitter still responds as usual, but if we’re writing some web program that, for example, does some data analysis on Twitter, the user might make a request to us. We might make a request to Twitter servers, they respond with what their response would be normally, and then we may manipulate that data and return it to the user. And this is actually a really common case. What I’d like to do now is actually explain how Hipmunk works a little bit, because we do a lot of this type of communication. Okay, let’s change our picture a little bit to be a little bit more about Hipmunk, because I’d like to explain how our architecture works. So in this case, this is still– we call users customers when they’re actually paying– and this is me–Steve–and this is Hipmunk servers. When a user does a flight search, what we do is we hit a bunch of our data providers where we actually get our flight data from. So the first thing we’ll do is we’ll take your flight search and we’ll send it to ITA, we’ll send it to an airline, and in some cases we’ll even send it to Amtrak, if that’s appropriate. Each of these guys are their own– these are companies who have their own services that we work with. So ITA will run our flight search, and they will send us data back. The Airline, too, will run their own flight search on their own system and they’ll send it back to us. And Amtrak will do its thing and send their data back to us. So then on our server, we have all this flight search data, represented by this blob here. We will manipulate all this data, collate it, make you nice results, and then we’ll send back our HTML response. So what we’re going to be working on in this unit is how do we make our server speak to other servers when there’s no browser involved. We’re still using HTTP, but we are now communicating over other protocols. We saw some of this in Unit 1, but we’re going to be doing a lot of it in this lesson, because there’s a lot of cool things you can do when you realize that you’re not the only service on the internet.