[MUSIC] So we've seen how we can take requests that are coming from a mobile client, like a mobile device, and create controllers that then have methods that are annotated with that request mapping and at request pa, parameter or at a path there in order to map those requests into invocations of methods on our objects. And to take parameters from the que, requests, either in the query string or in the body, if it's a URL enphoto, encoded form body or multi-part body or even out of the actual request path itself and map those into the method parameters that we need to invoke the method. The one thing we haven't talked about is, we've only talked about how we get data into our methods to invoke them. But we haven't talked about how the data that we're returning from our method actually ends up being converted into a response that's an HTV response that goes back to the client. And how that gets encoded and how that data that we're returning, in this case a Java object called contact, actually turns into something that can be sent in an HTV response back to the client. So let's look at actually how we can do that in Spring. So, in Spring, when we declare our response, we declare it by specifying what the return type is for the method. And what we want to do is we want to tell Spring that you should look at the return type, and you should automatically use it as the body of the response that you're sending back to the client. And we do that by annotating the return type of the method with @ResponseBody. And so now, when Spring sees our return type of our method, it knows, when I invoke this method, I'm going to take the return type, which is a contact, and I'm going to encode that contact into the body of the response that I am sending back to the client. The way that Spring does this is, it has a series of what it calls message converters that can convert data being sent in the body of a request from a client into Java Objects and then also convert Java Objects back into a body that can be sent out to a, a client that's, that requested something from the server. And, in this case, the default way that it, Spring tries to convert our data, is it will convert this contact object that we're returning into JSON, so that the client can receive JSON back. And it will be a JSON object that represents the contact. So whenever we go and send a request to /search, the dispatcher controller's going to go, it's going to see that slash search should be mapped into this search method. Any parameters inside of here that we have, request param annotations on or path var annotations, it will get the data for them. It will extract them and pass them into the correct location in the method. Our method logic's going to get executed. And then our method is going to return a contact object, which Spring will then convert because we've added the @ResponseBody annotation. It will then see this and know that I need to convert this object into the body of the HT response that I'm sending back. And it will convert that contact object into JSON and place it into the response body. So now we have a complete path from the client sending a request. Spring, seeing that request in the dispatcher servlet, figuring out which request mapping of all these annotations and all the various methods actually maps to the path in the request, figures out the correct method to invoke, handles all of the extraction of parameters, invokes the method logic. And now finally, takes the return of that method, converts it into response body, and turns it into JSON. Now, this is a huge amount of work that's going on. And what we're going to see is that it's actually not a lot of work for us. Spring is doing the heavy lifting for us. All that we're doing is telling Spring a little bit extra about our classes and our methods in our classes so that Spring can go and invoke the methods that we want on our objects and translate between HTV requests and invocations of our methods. And translate between the return types of our methods and responses that we're sending back that are HTV responses back to the clients. And what's really nice is suddenly, if you'll remember, we had this original setup where we were sending commands to our application. And then we wanted to be able to send responses back. And in this case, we've got a simple class that we can think of as an application there, Contacts Controller, is a component of an application that we can send a command to. We can specify how the commands that are being sent, in these cases, HTV requests with data in them, get routed to individual methods that we need to invoke in order to implement those commands. And then we can specify how the return types from our methods should be converted back into responses. So we've come full circle on that original vision. And the other thing is, is rather than living on a single host, all of this is happening over the internet. So this is running in the cloud on this side, and this is running on our mobile client over here. So not only are we going and actually creating a way of mapping the commands that are being sent to the individual objects that were created to build an application, but we're also doing it in a distributed manner so that the client can be remote, can send the commands over HTDP. And we can handle those HTV commands, map them into our objects, and send responses back, and do all of it on top of the HTDP protocol.
