Just write as you like. There is convenience given by the client, but there is also inconvenience. Try both and use them in the team. It would be good to choose one. Now, I will do a simple live coding. I created a new Spring project here. Let's run the code that calls the API and compare three methods. The first method is to create a secret of the application runner type, create an application runner, and write the code that runs when the Spring Boot application is initialized. There are various ways to write this code, as I have shown in my YouTube videos before. Please remember this well. Today, I have chosen this method. Let's see if it works well here.

I'll take a snapshot of HelloWorld. I'm in the state of running the co-pilot now, and sometimes code that I didn't enter can pop up like this. I'm not sure if it will be helpful or not. I saw this on someone's blog or lecture video today, so I installed it out of curiosity. What is this? It's like code for revenue or something. It seems to be a method or a class, and it shows how many conditions, branches, returns, and such are included in it. Based on this, it evaluates how complex the complexity is. This level is good, but as I go further back, oh, I feel like something needs to be fixed, or are you kidding me? In this way, phrases pop up now. I don't really like it, so I removed it, but it keeps popping up because I didn't restart. If you're curious, right?

Install a plugin like this for the revenue of the code. So, the first thing to do is the rest template. I was thinking about what to bring, and I will use a simple example of an API that retrieves exchange rate information. When you do this, it basically returns exchange rate information between US dollars and other currencies. What happens if you create this with a rest template? Create one template. Do you have to create a new rest template every time, or can you create it once and share it among multiple threads? You can create one and use it. Creating it every time is a waste. So, register one as a bean and use it, or at least define one at the class level and share it in the methods. I recommend using it this way. First of all, what results are coming back.

Since I don't know, I will receive it as a string. Just by running it like this, it won't work. Let me try printing it once. Okay, it's coming out as JSON like this, so what comes back is results, documents, etc. As you go back, you can see the code here. From here, the exchange rate comes out. The base rate is US dollars, and the exchange rates are in US dollars. If you keep scrolling down, you will probably see the Korean won as well. It also comes out in Korean won. So today, the US dollar is 1,317 won. It has crossed 1,300 won again. Now, if I just bring it like this, it's too plain, so let me take this out here once to see how much the exchange rate is for Korean won against the US dollar. Then, if I just return the body as a string, JSON will come in as a whole string. So, if we change this to a map type and define a Java class, it will be neat.

Because it's bothersome, in times like this, I usually looked at it as a map type. The key is a string, and what it receives is just an object for now. Since I don't know how it looks, then if we look at it earlier, we can bring it. So, when we now try to fetch the first element of Rachel, we have read it well. Next, what appears now is JSON. Through the Jackson library, it will map well. How should we receive this? It seems good to receive it as another map. By receiving it as a map, the key will still be a string, and after that will be the exchange rate, so decimals will come out, so we can use BigDecimal, or I will simply use double. By doing this, we can fetch it as a map, and within that, we can again use a map. If we print this out, not in USD but in KRW, we can precisely extract the exchange rate of the Korean won against the US dollar. Now, this is a simple way of using the RestTemplate.

You can simply end it by extracting the body when receiving it as an object, or you can also get other information such as headers if you receive it as an entity. When you just need to read it, it's quite simple, but it can be a bit cumbersome when you need to write something, make a post, or set various information in the header. You have to do a lot of work on top of that. So, this was the first one, and the second one is trying to use a web client. When I first encountered this, I was really enthusiastic. Oh, the copilot is great. It copies the code I created above and helps me create things like this. For now, I'm just creating a host here. What should I do here? From the web client, you can see what you can do next in this way through chaining, so even if you don't remember the order of things, you can easily see what you need to do at this stage by looking at this. This is what you see in this kind of report.

Now, this is the API that we're going to modernize. It seems like we're telling it to use this, right? So, after the GET, then provide the URI, and we'll put it here at the end. So, the body to Mono retriever actually, this is where the change happens. It fetches a response from the server, and from the response, what we are interested in is just the body. So, we converted the body to Mono. In fact, when we receive it as Mono and want to talk about it, we would need to talk a lot more. So, when we use it in a completely reactive manner, when we use it synchronously, we block it, keeping the current thread blocked. The web client runs on a separate thread in the background. The basic is that our netty client runs, and we run on the worker thread, and then we wait for it to asynchronously give a response, and we just receive it in the block. It's about receiving the current web request that is being processed. So, when we block it,

Then, the way to bring it will be similar to the one above. Copy this and paste it the same way, since we've used it once. Now, to fetch the same thing as a web client, you can create the code like this. You were able to get both pieces of information the same way. So, up to here, these were the things we could use before. You can choose which one to use based on your preference, assuming you have mastered the usage of each. If the web client is more modern, and later if you use a reactive approach, you can use a unified solution. If you don't think you will need to use WebFlux, then just use the REST template. It can be really challenging for those who are new to this. Now, the third method I mentioned, what was it? It's the HTTP interface that has been newly added. So, it looks something like this in general on the interface.

Annotation is attached to just defining the method signature. When you pass parameters, it binds how this will be sent to the URL. Then, typically, you put only the path part in the URI after that. In this way, you can put the server address or more detailed common properties at the top of the interface. However, when we use Spring Data JPA like this, we use annotations in the code that initializes something in Spring Data JPA. From there, we read the interface, dynamically create the class that implements it, insert the actual implementation code, and make it work. Perhaps soon, if you attach annotations to this part, it will automatically happen. But for now, you need to create it like this. The code for the process of creating a proxy that generates a class implemented as an interface type is a bit cumbersome, but let's delve into it from here.

I'll try to start how to make an interface. How to make an interface? This is, I will create a name like Exchange Rate API, not Monoiga, but I will receive it as a map. Just like this, it ends. Then, when using this interface in code services or in other beans, whether this is a code that calls a remote API or not, things like this are actually not really conscious. You can just use it. Whether it reads information from a database defined in a local pin or reads it from a cache, or really calls the API every time, you don't have to worry about it. We just use it. So, of course, if you open the interface source, you might see something like this, Oh, this is where an HTTP call goes in. You might be able to think about things like this, but anyway, writing the left client code is quite a cumbersome task. While writing it, bugs can also creep in.

And so, following the rules, if you write this well, it is very convenient. If I were to create API call code in Spring 6, I would use this. But now, in order to give an example, I need to create a proxy to write the code that actually allows it to be used. Since I'm not very familiar with this, I will try to practice by copying the code I had prepared in advance. First, we will create a proxy factory. There is a thing called an HTTP service proxy factory, and from here, it seems to internally use a web client adapter. So, there is a basic web client hole, right? We will pass that part to create the proxy factory. Once we have prepared up to this point, the next steps are quite simple. That is, [music], and you just need to put an interface here. Then, by reading the information attached to the interface, you can use this to make a REST.

Create an actual bean implementing the client, create a class, create a beam, and return the object. When returning, of course, return it as an interface type. So, you just need to call the API like this, simple, right? Since this is also a map, you can receive it like this. Of course, now I'm too lazy to create something like a DTO to bring this, so I did it this way. You all should create classes that can receive this if you are going to use this API frequently. Like this, let's check if the three calls to the same API work well. Let's see if it works. Okay, the third one worked well too. Those who have been using OpenFeign may replace it with this. I'm not sure what it's implemented internally, but it's not just a direct use of OpenFeign. Anyway, now, in order for us to use this, for example, what...

In services like this service layer, it doesn't make sense to put this proxy creation in API calls like this every time, right? So, typically, what we do is implement a bean with an interface like erapi, then register it once in the configuration class as a bean, and then use it by injecting it where needed. So, let's create that. Let's create a bean like this, create a bean object in this way, and the return type can be named erapi. You don't need to fetch it or inject it, just create a web client by default and use it. It would be appropriate to create a proxy with this and return it. Then, you can simply inject it in the service layer where needed. Since it's a hassle to create another bean, I'll just...

I will receive the injection here. When receiving the scale injection in the ER API type, it is okay. When receiving another bean in a method with an empty annotation, should I put Autowired? It's not necessary. In the case where there is a standalone constructor, it is possible to omit Autowired when receiving the scale injection through the constructor. The same applies even in methods with bean annotations. So, when receiving another bean through parameters in a method with a bean annotation, it is not necessary to add anything in front. So, when bringing it like this, there seems to be a name conflict. Then, shall we just call this API? So, the side using this is quite intuitive. You don't need to know what kind of REST is being used or anything like that. And should we receive this again as the fourth one? If we use it like this, it will be very simple. The side using it, whether using RestTemplate, API, or Http interface, doesn't need to know.

You can use the services provided by implementing the interface in the bean regardless of how you write it. Let's see if all four things can come out the same. Oh, it seems to be successful. I haven't used the HTTP interface in practice yet. I'm just starting the project now, but I think I will use this. One slightly cumbersome thing is that you have to create this one by one. In my opinion, like Spring Data JPA, maybe there will be something that automatically does this work. I searched, but it seems there isn't one yet. It might be created by Spring Boot or come out during a minor version upgrade. Anyway, for those who came late, this is a plugin called code completion. I installed it out of curiosity today.

I have removed it. So, the thing is, inside this, the complexity is 3, right? The thing is, even though it has not been called, there is a method anyway, so every time it returns, the complexity goes up by one. When using lambda, the complexity goes up again. So, now it has three complexities with a complexity of 3. Up to this point, it is very neat, indicating things like this. When I put this in or return multiple times, it keeps going up. So, if you want to keep this low, try using it once, and shall we apply it to Spring? In Spring, at the method level, is there initialization? It's a constructor, but the complexity is 12. There are many if statements, so each time this part comes up, it becomes complex, which seems like a very interesting approach, but I don't think it's very useful. I think this is complex.

If you think this is not code, it's fundamentally a complex functionality, not complex code. Well, anyway, while talking about templates like this, we looked into three types of last clients supported in Spring 6. Thank you.

Spring 6의 새로운 HTTP Interface와 3 가지 REST Clients 라이브 코딩

Spring 6의 새로운 HTTP Interface와 3 가지 REST Clients 라이브 코딩