Welcome to lesson 5, Request Parameters, getting at parameter data. Here we will extract data from the HTTP requests coming into our rest controllers. We will return textual representations of server resources to our clients. Our resources are Java objects, they need to be transformed into tags. For us, that will be JSON. We will also have the ability to customize the response with respect to headers by responding with the response entity where we can add our own custom headers. So far we have seen something like this with respect to extracting data from the request that's coming into a controller. I have a rest controller here with a single method Get parameter, the request object is being injected in. We're writing the Java code to get out the parameter employee. It's very long-winded, doesn't seem like a spring way of doing it. The first way we can have spring do the heavy lifting for us is to use something called URI Templates, where the data is embedded in the URL. You see the placeholder here, example.org/foo/userid, that's a placeholder. Doesn't have to be end, it could be anywhere in the URL, and below you see a tightening URL like the bar. Bar is in the position of where that place holder is, so it's considered that is accessible data that we can extract out of the URL. How would we do this? We know the controllers first of all. Rest controllers make use of dependency injection to delegate down to the root contexts. That's what I have here in this employee controller with the employee data. The next thing I have a request mapping of employee and a Get mapping tied to, and then we have this placeholder. What we're saying here is that if you pass in the URL of employee/something, that something is in the placeholder position of the URL. We can extract that using the app path variable annotation, we give it a name ID because we may have more than one place holder in our URL. We want the one call ID. I only have one here. So we extract that, pass it through converters, in this case to a long and then we use that long to delegate down to the root contexts and the data to return an employee object. Employee object is then going go through converters, ask them to a textual representation of that object, I JSON. If I put in this URL, work is the context root, employee, rest controller, and then three placeholder, I should get Jason Ross coming back in JSON format. In fact, it's being put into a response entity object, which might include headers and status. What you're actually looking at here is the payload. Were quite okay to do that, unless you want to customize the response entity. That means we create our own. Here, I'm returning a response entity.ok, that's saying it's 200 HTTP status code. I'm setting a custom header in this response entity builder that it's called. That comes out of the ok method of greeting. Value, hello world. Then the body is the payload for delegating down to the injected DAO. When you look at your response in modern browsers, you have DevTools, you can see my URL there showing the status 200, and you can also see the custom header, greeting: hello world. You see other headers that are generated by default content-type, it's application JSON coming back and date. Now perhaps different scenarios result in different status codes, and that is true. We have lots of different HTTP status codes, here's an example where I received the ID, I delegate Dan to my Dao, but I don't get an employee back because maybe the ID doesn't exist on the DAO or wherever the data is being sought from that DAO. Instead of returning a response sensitive, of ok, I can return a response sensitive.badrequest, since bad request doesn't have a body, you can see here when I mentioned before response entities, a builder, you have to execute the build command in order to build the response entity as I've done there. Why didn't I do that when we did the response entity ok? Because I used the body method and it does it automatically behind the scenes for you. The second means by which we can extract data is using a different annotation, RequestParam. We can see here that I have a method no longer where the URI placeholder, it's just a straightforward path. Path is the default variable since you don't always have to put it in. You might see me not put it in before. It's the only attribute it's considered the default. You can see my RequestParam. I'm looking for something called name.id. Where did that come from? Well, we can see the URL, employee/single?id=4. That's where it's coming from. It will extract it out of the query string and place it into the long ID here. But with RequestParams they don't always have to be present. Here you see in the first code snippet a default value if you don't find that request parameter. Secondly, you're saying, well, we'll accept it if you don't find it. It's not always required. This is an old way of doing it. The more modern if, that's the right word approach to do it is actually in the code snippet below where we create a Java optional, and then with the optional you would do a get, which would fall over if it wasn't there, more likely you would do or else and you could provide a default value there. This endpoint, as we can now call it, this method in this rest controller can actually satisfying two URLs. When do you use a RequestParam rather than a path variable? When it's optional. We talked about headers. We create a custom ones when we did a response. What about sending headers to my service? How do I get hold of those? Well, three approaches here. The first approach is you injecting the entire request and get hold of the header, right? Identify user agent. Well, Spring likes to do stuff for us, so maybe we shouldn't really be doing that it's very old fashioned. What about injecting in using app request header? Well, that's great. We can see, we can get hold of it. It's a string. But what if we don't provide it? It's going to say, I don't have that header. I'm going to be in trouble. I'm looking at my last example here to say that the request header is optional. What about combining both approaches, path variables and request parameters? Here's an example where I'm returning a collection. It will return a JSON array of employee objects. Path variable is a mandatory that part of the URL. I have to have them Request parameters are optional. You can see I have provided a path on my get mapping which contains a place holder for the path variable, mandatory, and then I put in an optional request parameter. I'm using that optional request parameter to filter an existing collection coming back from an injected DAO. If it contains something that is optional I will use it, otherwise I just say, does the last name contains anything really an empty string? This means that again, we have a single endpoint that can satisfy two URLs. Work employee search, Eric, with a RequestParam and without a RequestParam. We have a couple of labs for you to do. One more will follow one from the other both using path variables and request parameters. Once you've complete the labs I'll walk you through both of them. I'll see you on the other side.
