OpenAPI and Spring-Boot 4 - What's New? by Badr Nass Lahsen @ Spring I/O 2026

In this talk, Badr Nassar discusses the integration of Open API with Spring Boot 4, focusing on advancements in API design and security. He presents the evolution of Open API standards, notably Open API 3.2, and highlights the value of Spring Doc Open API in modern microservices architecture. The speaker elaborates on new features, such as the Scala UI for a better developer experience, and examines the implications of integrating AI with APIs. Nassar emphasizes the need for structured security protocols and versioning strategies for REST APIs, addressing the importance of human oversight in operations that involve AI agents. This session showcases practical demonstrations of API versioning techniques and the utilization of guardrails to ensure safe interactions with AI tools.

[music] >> Hello everyone. And welcome to today's session. First of all, um thank you to the Spring I/O team for the organization. And thank you for the your interest to this topic. So, my name is Badr Nassar. I'm the manager of the solution engineering team in EMEA for all machine at Palo Alto Networks. And uh today I want to share with you a topic that I like

a lot. It's uh Open API. How can we integrate it with the Spring Boot Spring Boot 4? So, originally I'm the creator of the project Spring Doc Open API. also I'm really focused deeply focused on security matters. So, I have been um uh working on Spring uh and also the evolution on machine human identities. And also I have written a book around the Spring Security. Spring Security

how we can secure effectively your cloud native applications, your modern microservices, and REST APIs with latest standards that we know nowadays. So, this is for the intro. So, our agenda today is uh fully packed to be honest. Uh We have a very short duration, but I will try to be maximum efficient. So, first of all, I will start with some history. So, we are discussing about the

Spring Boot 4. The current version of Open API is Open API 3.2. We will see how the these two topics evolved in the Java ecosystem. And how I would say we are unifying these two words with the Spring Doc Open API. But there has been a lot of changes. Nowadays we talk a lot about AI and modern modern developer experience. So, I will uh focus on two

new topics. Maybe you're not aware of. So, in the Spring Doc Open API it's Scalar. Scalar is a very modern UI to interact with the with APIs. So, you can consider it as the next gen uh for a developer experience when it comes to interacting with APIs. And um there is also another topic that we will cover today related to integration with AI agents because it's um

a trending topic enterprise level modernization. A lot of companies invested heavily on their business uh logic that is um developed with REST APIs internally, but now they want to achieve the move to AI and expose it as MCP uh I would say end points internally to make it consumed internally. But you don't want to develop heavily in order to expose these end points into MCP. So, I

will show you also how we can achieve it quickly with the the new evolution of the framework. First First of all, a reminder about uh the role of up Open API in nowadays. Nowadays it's a standard de facto. Um generally speaking when when you are modernizing your architecture you rely on Open API because you want to use it for design at the earliest phases. When you are

designing your APIs, you want to use it in the second phase when you publish your APIs to your consumers. And generally speaking it can be your front end developers, but also your applications that are consuming. And most importantly, you need to secure and govern these APIs. And with the Open API you have a standard to interact effectively with the uh with the the ecosystem. So, we have

you have security protocols that are normalized. You have standard ways how you interact with webhooks. And uh this is really important nowadays when you want to open your APIs to the external world. Always I start from the beginning. So, when we discuss about Open API it's uh machine readable in the left but also human readable. So, in the right with the HTML presentation for business. And you

get uh the maximum value I would say when you have all the actors of course together. But what is important is that in Open API 3.1 we have structured it by mainly having paths. You have the components elements and the webhooks. It's only three main elements that are mandatory if you want to define your your your Open API and expose it to the let's let's also discuss

some history about about the framework and how are we targeting the integration with Spring Boot 4. So, in each major Java release you had uh after it a major Spring release. Okay. So, this is the history. And in parallel there was also the evolution of the standard of the Open API standard. So, it started with Swagger uh 2.0. Okay. Uh initially it wasn't called Open API. And

afterwards we had to handle the new versions of of Open API and integrate them in parallel with the evolution of the of the framework. Mainly with the Spring framework and also with the evolutions of of Java. So, today we are at Open API 3.2, but most widely used nowadays um version is Open API 3.1 in in the ecosystem. And we wait also for some downstream libraries to

integrate and to support Open API 3.2 to make sure that also we integrate them into into the ecosystem. So, this is the state of the art right now. Generally speaking it's we are in a stable version of Open API that is really the most widely used in in the The main changes you might have noticed for example in the 3.1 if you have get HTTP get operations

you you can pass the request body. In the past it was it was prohibited. But nowadays it's possible with the new specification. Also the responses are not anymore mandatory in the Open API spec 3.1. There has been a huge simplification in terms of types. there is a there was a the move to the JSON schema which makes the definition of Open API is much more standard and

much easier to integrate. We can say with the with the external ecosystem. So, this is about the history in terms for Open API. the idea is to bridge the gap between Open API and Spring. So, with the arrival of Spring Boot 4 so, in November we we have a really complete and robust framework that is also enhanced in terms of performance capabilities. And also we have seen

some AI integration with the ecosystem. But what is the most important for us is the API integration. It's the API native integration. So, in Spring Boot 4 the major enhancement that we we rely on is API versioning. So, this is one of the topics that we will see today. Also historically in Spring Boot 4 you have you had also the problem details RFC that has been already

integrated and which is already in the framework by default supported. There There are other aspects that that are brought to the framework, but generally speaking they make just your APIs more resilient, more uh more let's say um safer. For example, the G specify to make sure that you have uh better or robust code in terms of null null check and making making your your code more resilient.

Now, in terms of numbers about the project, where are we right now? So, these are the latest statistics from from the Sonatype uh the Maven public repository where you have I would say all the artifact. And basically in the last quarter we had almost 300 million downloads of the Spring Doc Open API. So, we will see afterwards that there are different components. But we had almost 300

million downloads. And well, it's a project that started I started it in 2019. And now we are at around 300 3,700 GitHub stars. And what makes open source and in general this project live is the contributors. Okay. It's the open source contributors. So, we have more than 100 contributors uh in the project. And it's really the strength. Uh it's it's it's the open source community. Um also

what is interesting is that it's adopted at the enterprise level. First of all, the project was created because there there are some regulations. For example, if we discuss about the payment industry, in Europe you have instant payments. You have the PSD2, PSD3 that I would say mandates companies to expose in open API format for the payment industry. So, that's why, for example, you will find some financial

institutions, but also some some big tech companies, as you can see in the slides that are already adopting it largely in within their organization. So, this is about the general overview. Now, I will deep dive into some of the components. Of course, as we have limited time, I will focus on the new ones today for the live demos, but overall, these are some elements that we already

that are already supported. So, we support Java, Kotlin, and Groovy. For the observability, we support actuator. Um, and we support the both modes, reactive and the blocking or servlet mode that are also available in in the different implementations. You can choose. There is native GraalVM support. Okay, since Spring Boot 3, but now it's even more enhanced with the Spring Boot 4. Really really strong. And in terms

of security, there is also native integration with the Spring Security and Spring Authorization Server. There is integration as well with the serverless. As you can see in the ecosystem, there are a lot of things to integrate, but it was a requirement. So, serverless integration, so with Spring Cloud Function. Um, you can also expose multiple group of APIs in your in your app. So, there is native group

support, integration with Spring Cloud Gateway, and also with your CI/CD pipelines, because sometimes when you expose open API, you don't want it maybe in production, but you want it just to be built and generated in an offline mode by your CI/CD pipelines. So, this is also available through some and plugins like you have like some Maven or Gradle plugins that are available out of the box. Now,

we will deep dive more in details into I would say the architecture, software architecture of the project. So, the library is built on top of Swagger Core, okay? And there is a common module where you have all the main logic that is centralized. Now, depending on implementation, you might move to the reactive mode or servlet. So, you have to choose either the Spring Boot Open API Starter

WebFlux or the Web MVC implementation. So, this is if you want just to generate open API. But, sometimes, and this is the general ask of developers, is I want to also have user interface where I can test my APIs. Also, the request also for testers. Test teams. so you had you had originally the Web MVC UI. So, automatically, once your application is developed, the we there is

auto discovery of the endpoints and they are available. But, now with the new versions, we have also a Scala Scala version for developer experience that we will see. And also an MCP UI. I don't know for people that the developed the MCP endpoints. Just I would say in the room, is there anyone that is developing a MCP endpoints in the room or MCP servers? Okay. Okay, interesting,

cuz if you rely on MCP, the idea is to say I use, for example, Spring IA to develop my MCP endpoints. But, the problem the general problem is that how will you test it? So, you can have Java tests, but you don't have an equivalent in a UI mode to auto discover or what you have developed. So, what what developers do in general, they use an external

tool, a JavaScript tool, if you know, to to to I would say that you need to install externally in order to to test your MCP endpoints. So, it makes the the development process heavier, because you need to install different tools, different UIs, run two different servers locally in order to in order to to solve this problem or or just to test an MCP endpoint, whereas this thing

you can already achieve it locally. But, we will deep dive into this part more in once we progress in the presentation. So, we will start the first demo with a Scala, okay? Uh, so as I said, Scala is really first class uh UI that is developed and it's open source. There is an enterprise version, just you know, there are some some features that are limited. Uh, but

for the daily tasks, I would say for a developer, it's already it's already more powerful from my own experience than Swagger UI. So, it's developer first oriented. You you have it's very lightweight. So, for example, if you want to expose it through your CDN, it it will not take too much time to load. of course, it will be very performant as it as it's too lightweight. So,

I will start the demos slowly, okay? So, I will I will first of all um uh switch to IntelliJ and you tell me. So, here I will start with this demo. Really the simple one. How are we going to implement Scala? So, originally, if we take the the implementation for the first part is that we have the Web But, in addition, originally, people what they do is

that they used to declare the Web MVC UI originally. So, the switch to Scala is very simple. It's just it's just you need to declare to to to replace UI by Scala. It's the only it's the only change that you will have to do in your apps. So, for example, if I take an original project that that was using the Web MVC UI, so this one, as

you can see, it had this implementation, and we just switch the dependency and that's it. It's the only thing that the developers needs to do. So, if I I switch, I just want to show you the the UI and then we continue the So, now it's it's starting. I will just move to the user interface. so here I'm trying to expose all the endpoints, okay? I'm trying

to expose all the endpoints of a book controller, automatically, once the application started, automatically, we were able to discover all all the endpoints. So, for example, if I want to test, okay, I choose this endpoint. I have the parameters. I have the different types of responses. And simply, if you want to test, you have you have clean UI how you want to experiment, and automatically you you

will have the response. I automatically you have the response of all your all your REST APIs. Now, what is interesting is that in the you can generate clients with different technologies. So, for example, I have here you can generate different SDKs, but also when you make any REST API also if I come back, if I want to make any REST API call, here you have the different

languages that are available. And you can see it's much much richer than the Swagger UI and what is available with with with the Swagger uh logic. For example, let's say we have some fans of C, and you have the corresponding logic. So, so this is just to introduce the the UI, the new enhancement in the UI and what is uh what is possible. And now what I

want to share the next evolution in Spring Boot 4. So, this is related mainly to to the versioning. So, as you know, in the history of APIs, there were a lot of discussions about versioning and how we will achieve it in the at the enterprise level, but a lot of companies defined their own rules. But, the problem is that on the Spring Boot framework, it wasn't enforced.

And this is I would say the strength in general of frameworks is that we can enforce some rules. So, now you have really robust framework with the problem details, with the the versioning aspects that are already there. For example, we will avoid to have a lot of duplication. One of the advantages is that all a lot of boiler rate code that you you need to maintain hugely

maintain with this new version you don't have to do to do it. But now that you are developing this APIs, you also need to discover it. So how will Springdoc open API expose it into open API format because this is the challenge. So we will see that we will cover the four strategies. So the first strategy path segments as you can see that you have the version

in the path that is defined. You the query parameter. So in general you the version as an argument of your query parameters. Third one is the request headers. And the the fourth one is the media type. So in the media type you can also pass the version. So this is also something that we see also often. outside the framework allows you have different strategies. But generally speaking

you see in terms of best practice when you define a strategy within an organization or within an application, you should be consistent. Okay. So this would be my advice for a versioning in general when when when it comes to implementation at large at large scale. Now I will I will show few demos for for the for what we will call the the versioning and then we we

can move with with the MCP and the IA part. So here all the demos that I'm showing at the end of the presentation I will share the GitHub link. Okay, so everything will be available. So we'll start again from the beginning with the dependencies in our project. what do I have? So I'm having web the web and web MVC UI. So this is what you people already

do when they use Springdoc open API. Okay. So here there is no no big change. Now in terms of versioning, I will go to the web config. So in this example in this example I'm using the media type. Okay, in this example I'm using the media type and I'm allowing two versions. also what is interesting to see to the same example in this demo flow really the

same example we will switch it to the different strategies. This is the idea. Okay. So here we have the first strategy as media type and we can see that we I would say the the versions and the media type that is that is corresponding. For each endpoint, so I have slash user media. I have different responses. So I want a different response for the V1 and the

V2. Okay. So we have two different DCOs. First one second one. Okay. One is with two attributes, second one is with three attributes. that's it. There is a little detail here just to handle the the versioning. So if for example someone calls with slash V1, we want to remove the the prefix. Just to I would say you can call it as syntax syntactic preference. and that's it.

So I will start the app. So this one is using the web MVC UI. So at this moment we will we will use the Swagger UI. So this is the first example I'm having the media type. So in the response as you can see we have the two generated. Okay, the two the two media types that has been generated. First one if I test it the ID

with three attributes that we mentioned. Okay. And if I test the second one So I'm having the ID with just two Okay. So in this in this curl or in this HTTP request we pass the media type and depending on the media type we have variant response. So this is pretty standard but it's handled also in the open API description and in the Swagger UI it's natively

supported. Now we will move to the second strategy. And for here let me just check where we are. I'm having in the same project. So now let's switch to the paths same same logic. Okay. I'm having the The web the same parcel but what is important is here the definition. So to have path versioning we need to pass use path segment. Okay. So this is the main

the main difference and if we go to the So I'm having two different syntaxes just to show you also the strength of the framework that we can support different ways of versioning. So we have the slash V and then the version with the the users or slash the version directly. So this is also important to know in terms of syntax that we can also support path definition

that are available in the framework. So it's the main difference. So I switched the project we again. Let's see. And here instead of one endpoint I'm having two endpoints, right? Because I I'm versioning with the path. Okay. And same logic. So if you test So you have and here we'll have four. Okay. So this is for the second second Now let's see another strategy. It's the it's

the request header. let's switch and check. I will try to go fast just to make sure also we cover some other stuff. So as you can see here we go with the request header. This is really the main change in the in the definition. And what is important is that here you see I'm using slash users with the version. One change that I have in this type

of project just to show you also the difference in terms of presentation. So here I switched to Scala. this. What should be or is the application started? It's not the right one. I believe I haven't I haven't started the application. Okay. So here I'm having the the application and I'm passing as you can see X API version. So this is what we had defined is in our

configuration class. And same logic we can test. So with the V1 and with the V2 and of course if you want to discuss for example here there are some interesting stuff. For example, you can also ask I I will move to the next step but you can also ask so there is an embedded IA agent with limited of course access because after that you will need to

switch to the enterprise version. But you can also ask the IA agent to make this API calls for you and also test just test the the responses in with with with your input prompt. So now we move to the last strategy quickly. So the last one that that remains is the query param. I wait this time I need to make sure that the application starts correctly. And

let's see how it's presented. So as you can see here in the version I'm having two versions V1 and 1.0. And why we have this? Because it can seem not consistent. So basically in the presentation here we used query param. But the difference is that in the controller, okay, we are using this one version and this one version two. With with this syntax and in my in

my definition in my definition when I try to access I will I will have the API parser Okay. that will change the prefix. So, if I'm having {slash} V1, it will become one. And if I'm having V2, it will become two. here, just to make the test, and we can wrap up this part. So, in in the This is the version. Okay, this is the version, V1,

V2. And if I switch to V2, we will have again the new version that is that is So, it's it's always I would say integrated smoothly, and this is my message. It's The choice is yours if you want to scalar or you or the Swagger UI implementation. It's Really, it's transparent. And it's I would say natively integrated with the with the with the Spring Boot and the

versioning, you have almost zero configuration to do. As you can see, I didn't put I didn't add any code that is Spring Doc. Okay, this is the beauty of um I'd say of this integration. Now, let's move to some other enhancements that are So, what we are trying to do nowadays is that you are having um Open API specs. You are having already your business logic. It's

already built internally, but you want to expose it to AI agents. Problem is that you don't the impact of an AI agent. Okay, for example, they can have um some dangerous operation, like for example, delete. It can delete tables or it can delete some sensitive data. So, how are we going to control this safely since the development phase? This is really the challenge. So, the idea is

to introduce uh some guardrails, some general rules. So, what I will show is that for some mutating methods, we will automatically in different in the framework enforce the what we call human in the loop validation. In general, if there is any creation by default or deletion, automatically we we say in the framework it will be it needs human validation, unless the developer or in the configuration we

decide we decided that this method is safe, we can allow the AI agents to call it to change the state of the data in the company. And of course, you will have a central endpoint where you can discover all what you have developed. Okay. So, for people that remembers the uh for example, in SOAP, okay, you have the um WSDL or you have the registry of all

your operations. So, it's almost the same. So, you will or your or your tools that are exposed to your app. Also, another problem that we are trying is what we call the black box problem. So, generally speaking, um AI agents are subject to hallucinations, right? But you have developed in your companies very reliable and consistent APIs. So, if you guide your AI agent for the business logic

to call directly the right API, job is done. On the other hand, you need to to make sure that any destructive action is under control. And this is the big risk. So, the idea is also for the risky operations, to make sure that we have the right guardrails to avoid any any impact or any damage in production. And this is the shift. This is the paradigm shift

that we are having right in the development and in developer ecosystem. Is that we are moving from a solution that is primary centric to to a solution that needs also primary centric to AI agents. Okay. And this is what is really important. So, traditionally, I have shown the try out button, but now what I need is to expose to the AI agent the most relevant description. Okay,

the more the most relevant way to consume my APIs. And generally speaking, the Open API spec, how it was built, it wasn't built for AI agents. Um so, we will try to focus on this, and I will try in the presentation to focus mainly on MCP. Nowadays, you know MCP is one of the most used protocols for AI interactions. It has been standardized by Ontropik, but it's

largely used. Um There are a lot of changes, especially on the security landscape when it comes in regards to MCP, but we are evolving into a direction where nowadays it's the most used uh protocol for AI uh the idea of the of the bridge that you that you we put in place is to automatically introspect all your controllers and expose them as MCP endpoints. Simply So, what

is done behind the scenes is is what you can see in the table. So, each operation ID will be automatically transformed into a tool name, its description into a tool description, its request body into an input schema. And we you can also inherit all the security aspects that you have in Spring Security. Spring Security is very strong. People in MCP, they are still struggling how are are

we going to handle authorizations, but Spring solved it many years ago, and we have really robust authorization policies that you can just extend and apply to your endpoints, to your MCP endpoints. And this is also what we will see uh in the demo. Um an example I would say an example of prompt that you want to to share and expose in terms of description for your for

your AI agents. Let's suppose that I I didn't have the MCP tool description. Let's suppose that in your application you didn't have. So, how will the AI agent guess that to call this API, you a type UUID, for example. And how if I want, for example, to add some guardrails, like I don't want to password reset or some sensitive how can I enforce this? Because I have

the front-end developer that is consuming my APIs, but also I need to make sure that my AI agent has the most accurate description. So, what you can do is that you add an annotation MCP tool description that will be automatically exposed in for for your AI agents. Also, I discussed with the about the guardrails. So, this is the default configuration. You have get, head, and options that

are by default allowed or whitelisted, but you can decide you can decide in the app. Um so, we have a customizer where you can decide which operations you would like to allow. So, which method, but also which endpoint. Um and we integrated the human in the loop, which means that automatically, if your your operation is under control of a human, it needs a human approval before the

AI agent proceeds. Okay. And all this you can apply it, I would say, in a granular way. Uh some other interesting aspects when it comes to MCP and in general, you need some monitoring of all what you are doing. uh you you have in the dashboard, you will have also the ratio of the mutating non-mutating non-mutating methods, but also you will have some performance indicators that are

very very important. So, for your tools, for all what you are developing, so you have the MCP call that will the MCP endpoint that will call the REST endpoint. Sometimes there might be a latency, so you need to investigate. So, all these details, you will have them in the UI. And one of the also the most important aspect, because that's why also we say that sometimes the

Open API description is not enough, is the token conception. So, in for your context windows, the idea is to make sure that it's the most accurate for the AI agent. Imagine you have huge response. So, automatically it will wipe or it will reach the limit in your context window, and also it you will consume more tokens, so it will cost you more for this type of interactions.

So, with with this vision about the the size or the number the size of the payload or the number of tokens that you are consuming, you can also interact to make sure that what you are exposing for the AI agents is tuned for the AI Okay. And we have seen it sometimes with the versioning, where sometimes you can act on the DTOs or some some aspects where

you can have more lightweight exposition. So, with this we reach the to the demo. I will switch to the code just to show uh, an example. So, in this example, I'm having an MCP server and an authorization server. So, I'm trying Normally, you don't need the authorization server if you want just to play with it, but here I'm exposing it over internet. Uh, so I prefer I

prefer that we have proper authentication before. So, uh, it's uh, integrated with the Spring Community project for the authorization uh, for the authorization server. So, what is important? If I want MCP expo- exposition, okay? So, here I'm having instead of the web in starter web MVC, MCP uh, in or scalar or the swagger UI, here I use MCP. It means that I want to expose my endpoints

as MCP for for the external world. There will be an UI also that is available more for development purpose that you can disable for your Yeah. Um, so this works. So, what will be done is that under the hood, we will rely on the Spring IIA starter MCP server. And you don't have to code yourself the implementation for Spring IIA. So, combining these two uh, dependencies automatically

exposes your REST APIs as MCP endpoints. Okay? Now, to see the the examples, I'm having hello controller. Uh, so I'm having a controller with the some uh, um, I'd say some operations. And um, as you can see, I'm having pre-authorized. So, for example, for this call, I the guy needs to be authenticated and you can also apply uh, or enforce uh, other policies. So, the idea is

that by default, I want to extend this description. So, it means this description I want it also to be for the MCP server. what if I I what if I wanted to to to uh, to have a proper description? So, you can also rely on the MCP tool I'm just trying to see if I'm having tool name. Example, this one. Let's check uh, this one is not

the right one. I'm just want I just want to show you how can you enhance the description. So, originally, you have the open API description, which is the operation, but what we have seen in the slide is that if you want to enforce the description, you can use the MCP tool description annotation and this one is Spring Doc. Uh, if you check here, you will see that

Spring Doc annotation. here we have the demo. We have we have these examples and um, what I want also to to show is that in this project, I'm having few controllers that exposed, but also I have some native tools some native MCP tools that don't uh, rely on on uh, REST. So, we can also discover them. So, in the discovery, we'll have the native MCP tools, but

in addition, the REST the REST based MCP tools. So, the native MCP tools are there. Uh, if I check, so here as you can see is tools. Spring IIA tools that are also So, if I move to the demo, in this example, I have deployed remotely and what you can do is that you can interact with the server. So, each time there is an interaction, we will

see it in the audit logs. Okay? And we will have some data about uh, what has been done already. So, the audit logs here, you can also decide to clear it. I cleared it mainly for the sake the sake of the demo. So, let's suppose I want to make a call here to find by ID, I get stopped. Okay? I get stopped. Uh, I have uh, 4001.

So, what you can do I I will simulate the call. Uh, here it will be So, I will simulate this. Normally, I have to hard code it, right? But as we are in a demo mode, I will use the client ID client secret. So, the best practice here is to store the client ID client secret. It needs to come from a secret manager or the identity needs

to come from another source, but this is the spec. Uh, this is this is the spec. You need to pass a client ID client secret. And if I'm in development mode, it's not too bad. Uh, invalid client because there is a slash. And no one told me that there is a But look, um, then uh, so we have the identities just to show you that uh, we

can see So, this is really a valid JWT token uh, that has been generated. And now if I test, because I didn't create, but I have 4001 because I haven't created the ID doesn't exist, but I have different error. All these interactions, okay, right now, we start we we start uh, seeing them. Now, if I move to to the IIA agent. So, one of the most used

I would say agents is cloud, right? So, what I will do is that um, I will show you that I'm having an MCP So, I declared my MCP server and I can tell him I can uh, Okay, MCP. And what I I what I will do, so it asks me to authenticate. So, as I'm asked to authenticate, I will authenticate as user. Authentication successful. And then um,

>> [clears throat] >> I will tell get Spring Doc demo MCP. So, what what will be done right now, I just want to achieve a discovery of all the available MCP tools and get get the So, let's wait and in parallel, what I can also show is that we have we can So, normally, what it will show me, okay? If I execute here, it will show me

all the sessions that we have at the Spring IIA conference right And also it it it should it should show all the tools that I have. So, all the tools that we have here, like find by ID and everything, we should be able to Now, it's taking some time I believe it's the connection, right? Let's just check. Okay. Let's check for for the connection. But we we

need to be patient uh, with IIA agents. I you know, you don't need to force. And here we are. Okay? Now, um, so for example, if I want to make a call, I would just show you one thing is that if I want to make a post, I want So, I have multiple ones, okay? If I want to create a book, okay? So, here I have books.

So, I want to create. I I want to show you just the human in in the loop. So, I I we we will intercept because it's a mutating method, we'll intercept the call. what should happen is that we need to ask the human to approve. This is the idea and all these steps should be I would say they should be traced. Um, okay, I will say I

will choose one because now he asked what what are the what what are the elements that you want to create? I almost exceeded the time. I just wait to run it and we will be we will be done, but the idea here is that once the call will be made, what we want to see is that in the audit logs, it has been intercepted and a human

approved and then the IIA can continue his work of the of the REST But for some reason, there there is more latency. This is also the beauty of the live the live demos. Wait. And in the meantime, just to show in uh, um, in the UI. So, for example, the first action when I said uh, each action that I'm trying to make, each action, we will see

it here in the logs and automatically, once the guy will approve, we will also see it in terms of status. Also, what is interesting is that you have also the role of the users. You have the payload. You have also the information about the response size and the number of tokens. It's very, I'd say, it depends on on the presentation you have, but I believe I can

make it clear. You see, you have the size of the payload and the number of tokens that are associated. see? So, here it asks me to proceed. So, as you can see, the request has been intercepted. It asks for human approval. Okay. So, here, as it asks for human approval, automatically it has been traced. Okay. Human approval. So, this is with the remote. And automatically here, I

say, "Okay, I want you to proceed." And the idea is that at the end to approve. Okay. And the idea is at the end to approve. And we can we can then you see, as I approved, automatically now it's okay. So, you have all the steps. And what is important is that you have all the details of the LLM intent. And all all the data that is

that is associated. And with this, we will reach out, I'd say, the end of the presentation. So, just to wrap up is to say that with Spring Boot, you are having the architecture of an I'd say, an AI native for your back end. It's already there. You have all the elements. So, really happy coding. And thank you for joining this session. Thank you for joining me today.

And we can keep in touch on LinkedIn or on other sessions. Thank you so much. Thank you.