 So far, we've been working with the actual QTCP socket and with the raw HTTP protocol. That's not the most efficient way to do things. You don't want to reinvent the wheel, especially when Qt has gone ahead and made a Q network access manager class that does all of that for us. And it's extremely simple to work with. So this is actually superseded old classes like the QHTTP class. You may see in older tutorials and, well, I hate to say it as easy as this is to work with. It can be a little challenging to really wrap your head around. What does this really do? Well, it really encapsulates HTTP at its very core. You can get, you can post, you can delete, you can get the header, you can do all sorts of things. And, well, it's all working through signals and slots. So simple is about the only way I can put it. This is ridiculously simple to work with. We're just going to do a real bare bones example. Let's flip into our code. I've already got a bare bones Q object class. And we're including the network library. So let's go into the worker here. We're going to copy and paste some includes and go over them. Q object for obvious reasons, Qtabug for obvious reasons, Q network access manager. This does the heavy lifting. The network access manager works with what's called a Q network reply. This would be the response back from the server and a Q network request. This is the request you're making to the server. Q authenticator, that's for any username and passwords and Q network proxy just in case we want to work with a proxy server. Let's go ahead and make some slots. In the HTTP RFC, get is the means of downloading something. So whenever you get, you're actually getting it from the server. And post is a way you would actually put something to the server. That thing that you're putting to the server, it could be a file, it could be data, it could be pretty much anything. So we're going to send it a Q byte array and simply call it data. Now we're going to make some private slots and really we're just ripping these straight out of the documentation from Q network access manager. We're going to say authentication required, encrypted finish, et cetera, et cetera. I've already got these queued up. So I'm just going to copy this, save us a lot of typing. There we go. Ready read. Well, very, very self-explanatory. This is just simply when we know there's data from the socket. Authentication required. That is when, well, the actual remote server saying, hey, I don't really know who you are. You need to authenticate encrypted because we could be using an SSL socket finished. This is when the reply is actually finished. Remember there's a whole handshake that has to happen and the protocol itself may go back and forth between the client and the server several times. So let's go back here. Network accessible change. That's basically meaning whether or not the network is actually accessible. Remember that Qt runs just about everywhere so you don't know if, well, you're on a mobile device, if you're on an actual computer or laptop, pre-shared authentication key. This is basically the SSL handshake. This is the pre-shared authenticator, proxy authentication, pretty self-explanatory. This means we're talking to the proxy server and SSL errors is everybody's favorite. Whew, that is a lot. All right, let's go ahead and let's make a variable, let's call this manager. So really all we need to do now is, well, you got it. Create our signals and slots, connect them all up and fill out our implementation. And our actual constructor here, I'm going to just get a lot of this out of the way. All right, so we are connecting the Qnetwork access manager authentication to authentication encrypted, encrypted, network changed, pre-shared, proxy and SSL. Pretty simple, pretty easy to understand and wrap your head around. Yet, this is where we're going to actually make the connection and we're going to get something from a server. And we're going to say Qnetwork reply, and this is going to be a pointer. And notice how when we say manager, we get a whole slew of things we can do here. Get put head post. In case you're wondering, we're just going to go over a very high level. Get downloads the resource. Put is a special way of putting something out there. Basically if you want to put some sort of file, that's where you would put it. Head gets just the head, but not the actual document. So let's say we're actually getting a four terabyte file. Well we don't want to grab the entire file. We just want to grab the information of the file, so we know how big it is. And then post post data out there. And then there's a whole slew of other things you can do. We're just simply going to get, and we're going to get a Qnetwork request. And this request is going to be a Q URL of the location. Seems pretty cumbersome and there's a lot of confusion what's going on there, but really all we're doing is we're saying Qnetwork access manager, go get something from the server. This is the location we want it and we have to give it in a special format. We have to tell it, hey, make a network request and we want to know the reply back from the server. But because we're getting a reply and this is all going to happen behind the scenes asynchronously, we want to connect up some signals and slots here. So we're going to connect the reply. We want the Qnetwork reply. We want the ready read and we want to connect that to this ready read. Notice how we are not doing a direct connection. We're just doing an auto connection and that's because it's smart enough in the background to know what we want it to do. One of the very few times I'll actually trust that. Post is literally almost the same thing. Let's go ahead and let's just grab this whole thing and we'll do a little bit of surgery on it in here. We're going to post a server and we're going to say we're going to make a network request and then we want to actually set that request here. And what we're going to do is we're going to set a header. If you're not familiar with the HTTP protocol, there's different headers that you can set. For example, the connection, the protocol, what sort of content you allow, things like that. We're going to do a Qnetwork request and we want to do a content type header and we're going to simply tell it, hey, we're going to send you just plain text. Probably a much easier way of doing that. So we're basically manipulating the raw header of that request using the Qnet request content type and we're going to set that to text plain. That's a mime type in case you've ever heard that before. Mime types basically tell the operating system what sort of data is in there. So text plain would be something you'd open up in a text editor. All right, now we've got our network reply. We're going to take that reply. We're going to say manager post and we're going to send it the request that we're creating here. However, we also need to send it the data. So we're just going to make a copy of that data and then we're going to connect up ReadyRead with ReadyRead. Pretty simple, pretty straightforward. So why do we have to do this? Why is this step even required? Well basically we need to tell the server what type of information we're sending. That way it knows what to do with it. Some servers, if you skip this step, it's just going to say I don't know what this blob of data is and it's just going to ignore it completely. All right, ReadyRead, this is basically going to say, hey, we've got some data back from the socket and we want to do something with it. Click the wrong button. There we go. So ReadyRead and let's go ahead and let's get the information back from this. So we're going to get the queue network reply and we need to cast the sender. So we're going to do a queue object cast. Remember sender is just a pointer to a queue object so you have to cast that, otherwise it's just going to not have any of the information that we really want. If we actually have a reply, then we're going to do something with it. In this case, we're just going to spit it out under the console and we're just going to read all bytes. There we go. Nice, simple, easy to work with. And then we're just going to fill some of this in. We may use this in future tutorials. Let's grab this network changed. I'm just going to flush this in real quick just so we can see what's going on under the hood in this class, get all these things wired up, make them look pretty, give us a good save, give it a build, make sure we didn't screw anything up. You see, we get a lot of these unused. So let's fix these up real quick. We're just going to simply say, queue unused. Very simple way of getting rid of those. Now I once got asked, why do we even worry about these warnings? Well, you kind of want to clean this up as much as you can because warnings can actually lead to errors. That's why they're called warnings. Most warnings, to be brutally honest with you, just really mean nothing. For example, is it going to crash for our program if we don't use this reply? No, 100% will not even matter. But someone somewhere out there is going to say, I downloaded the code and there was a bunch of warnings. So now we can give it a good build. There's zero warnings, zero errors, and everything's good to go there. Now that we've got this in place, we can go into our main. And let's just say, include at our worker, I'm going to say, got some notes, misspelled, of course, queue network access manager really encapsulates the HTTP protocol, includes SSL by default. So we don't have to do any real brain surgery here. Let's go ahead and say worker, we're going to get a cubite array and we're going to call this data. And we can actually do some pretty cool things with this. Let's say data, dot append, and we're just going to send it some parameters. So really what's going on here, and I'm going to actually just kind of, for the sake of argument, add this in here. What we're doing is we're just adding parameters. And this is just a simple way of posting something out onto a website. Parameter is a key value pair. So your key equals value, the ampersand really means, and another one. So if you've ever been in a conversation with someone who talks a lot, they're like, and another thing, and another thing. That's really what's going on there. So you can just chain these out pretty much almost infinitely, as long as the server will take the request, you're good. There is a hard limit, but it's actually pretty big. We're going to post this. And I'm going to copy and paste here, rather than even try to type that out. There we go. So we're going to post to postman-echo.com slash post, and we're just going to post the data right here. So really what this is going to do is it's just going to mirror it right back in. So there we go. So what the postman-echo website does is it just returns a JSON blob of the data you basically just sent it. So you can see all of the information pretty much right at your fingertips. There's our parameters, accept language, English, contact type, plain text, user agent. Notice how it is actually trying to mimic Mozilla 5. Pretty interesting. Forwarded port to 443, meaning it forwarded it to an SSL port for us, and there's the actual URL. We could have very easily done something like this. And let's just comment this out real quick. It does essentially the same thing. So the difference between get and post is actually pretty subtle. You got to really kind of deep dive, but you notice the URL. So get, you're actually getting a document, and you're trusting that the server is going to take this, and it's going to say, hey, here are the parameters, do something with it. Whereas post is something completely different, even though the differences are very, very subtle, where you're basically saying, hey, do something with that data, here's the data. Notice they're very distinctly different commands. But from a use case, they look pretty much identical. Let's just face it. Qt is extremely complex, and it has a massive learning curve. But once you learn it, you can do just about anything. Unfortunately, learning Qt is a challenge in itself. And if you've tried learning straight from the docs, you've probably become easily frustrated. While they do a really good job, they're arguably some of the best documentation in the world. They don't go that extra step and leave a lot of people guessing what to do. How do all these things interconnect? That's why I started developing videos. I've done videos not just on my own YouTube channel, which you're watching now, but also on the official Qt Studios channel. And I've started doing video courses out on udemy.com. Right now, I have the Qt Core series. It covers beginners, intermediate, advanced. So it'll take you straight from Hello World, all the way up to building a complex, multi-threaded, encrypted TCP server. On top of that, if you don't want any of this, you can still join the Voidrom's Facebook group, which has a pretty flourishing group of developers. And we discuss everything, not just Qt. I hope to see you there.