REST APIs in Servoy – Robert Ivens
Robert Ivens talks about REST APIs and the different ways you can build them in Servoy
REST APIs
- REST APIs are essential for accessing services exposed only through APIs and drive modern software development.
- REST stands for Representational State Transfer and is an architectural style for distributed hypermedia systems, not a protocol like SOAP.
- REST uses HTTP methods like GET, POST, PUT, and DELETE, corresponding to create, read, update, and delete operations (CRUD).
- Responses are provided with status codes: 200 series for success, 300 series for redirection, 400 series for client errors, and 500 series for server errors.
- A request consists of a header and a body, separated by an empty line. The body contains the request’s content.
- Endpoints are defined by the HTTP method and the URL path. The resource is the result returned from an endpoint.
Building REST APIs in Survoy
- In Survoy, there are two ways to build REST APIs: using the REST WS plugin or the Velocity plugin.
- The REST WS plugin provides specific methods for handling GET, POST, PUT, and DELETE requests based on form names.
- The Velocity plugin offers more flexibility and includes reporting, REST, and web page serving functionalities.
- With Velocity, the entry point is the VR as in flos report get context method, which provides a request object containing extensive information about the request.
- Developers can access various request details, such as method, cookies, headers, sessions, and request parts, through the request object.
Best Practices for Building REST APIs
- Use nouns to represent resources and the plural form for endpoints.
- Use hyphens to increase readability in URLs and avoid underscores.
- Use consistent naming conventions and avoid nesting endpoints too deeply.
- Use query parameters for filtering and avoid verbs in endpoint names.
OpenAPI (Swagger)
- OpenAPI (formerly Swagger) is a specification for describing RESTful APIs.
- It allows for easy involvement of stakeholders in the design process before coding begins.
- Changing a specification is cheaper than coding when designing.
- Tools allow for the use of a mock server and code generation for various languages.
- The downside is that regenerating code after spec changes overwrites all existing code.
- The general structure of an Open API specification includes info, host, paths, external docs, and components.
- Components allow for code reuse by storing schemas, responses, parameters, headers, and more.
- The Swagger editor provides a preview of how an API would look in Swagger UI.
- Endpoints can be grouped together using tags.
Roar and OpenAPI Router
- Roar is a Svelte module that uses the Open API spec to map endpoints to methods and performs validations based on the spec.
- The speaker introduces a new open-source library called “open API router” that simplifies the development of APIs using Forge.
- The library handles repetitive tasks such as validation and error handling, allowing developers to focus on their business logic.
- It uses the OpenAPI specification to define paths, operations, and request/response structures, ensuring consistency between code and documentation.
- The library provides a standard context object that can be passed to methods, allowing for easy data sharing and manipulation.
- It validates requests against the OpenAPI specification and returns appropriate error responses if requests are invalid or not supported.
- The library works seamlessly with the Velocity Report plugin, allowing developers to easily integrate it into their existing Forge projects.
- It does not currently support the REST BeWS plugin, as that plugin handles endpoints differently.
- The library supports various authentication mechanisms, as authentication information is included in the request object.
- Developers have the freedom to handle authentication and create custom responses using the request object.
- The speaker plans to add more validations and vocabulary from the OpenAPI specification in future updates.
Logging
- Logging everything that comes in and out of the API is strongly advised to gain visibility into what’s happening on the APIs.
Right. So I wanted to talk about REST APIs in servoy. Who has built some REST APIs in your life? All bunch. Oh, nice. OK, cool. Who is consumed REST APIs as well? OK, cool. So I’m done. OK. Thank you. Thank you. So I guess this slide to the, you already know what that’s about. So why would you need a web API? Well, there are so many other services like, like, article administration and other services that are only exposed by REST API if you want to use those services. Yeah, to talk about those REST APIs. Really, REST APIs or APIs are the ancient of the models software development. Now, so if you got a product, you probably want to open that up as well using APIs. You don’t want to give them direct access to your data, using a database connection or something. So you have to create an API for that. And then in the end, you might want to publish that API to some central API help or something like that. Or, or, you want to. We have a website. We’re on it more later. So what is REST? REST stands for a representional state transfer, which was first coined by Roy Fielding when he wrote his thesis in 2000. And the thesis was about architectural styles and the design of network based software architectures. And it was an architectural style for distributed hypermedia systems. So it’s not a protocol. It’s a style. Like, so it is a protocol. So REST uses the language of the web. So it uses HTTP methods like the GET, to post the boot delete methods. It’s usually translate directly to like a create, or a read, or an update, or the delete statement, essentially, usually called CRUD. And then you give responses back, usually, like with these series, 200 series, that’s a success code, 200 success, 200 one is created to record something like that. 300 is read direction codes, or multiple of those. Or you have some, some, some, provide some bad data. So you get the form on the back as a client there, or you don’t have access, get one back, et cetera. So that’s the 400 series. And if you get an error, an exception on the server, then you usually get a 500 in that range back. So that’s the language really of, of the web, really, of the HTTP. So we’re going to talk about a lot of things and column that by name. So let’s, let’s look at how things are named really. So here we got a request. This is actually one thing. This is not two things. So yet you have the header. This guy’s post to a customer, a customer, it’s the protocol, it’s the 1.1. The host name is in there. And some other stuff in there. And then the request body is divided up by an empty line. And then you have the request body of your post, this effect. So, so this is really what is being sent over to wire. And also what you get back actually. So it’s not like really weird format or something. It’s just text, really just text, where the header and the body is divided up by a single line, an empty line. It is also why you want to put as much stuff in the body and not in URL when you want to encrypt it. So if you use HTTPS, then you get an encrypted connection. If you put stuff in the URL, then it’s visible. You put it in the body where that is, and that will be equipped. So here you got the request body, we’re talking about response body, that’s sort of the same thing. So, talking about endpoints, URLs, routes, paths, we’ll get really confusing really quick. So we’re talking about here a URL, HTTPS, local host, port number, and please, what to, let’s be as is the protocol. Can be HTTP, HTTPS, that finds the web protocol. The host, it’s not host, name, it’s host, is local host, because it can also be IP address. So then it’s not a host name. And then you get the port, code, port number, and then everything behind that is the path. All of your URL. Everything behind the protocol is the route. And if we’re talking about an endpoint, then we’re talking about the HTTP method as well, which is in this case, the GET. So we’re talking about endpoints, it’s not just the URL, it’s also the method. And then you get a result back, and that’s called a resource. So actually, if you go to a website, you get a page back, that’s the resource of that URL. And if you do it with a browser, that’s usually GET. So from that endpoint, you get some HTML back in this case. It’s an example, you get a JSON back, which is the resource of that endpoint. Okay, so building a REST API, well, with the in-servoy, there are two ways of doing that. You can use the REST WS plugin that’s bundled with server. And that works in a specific way, where your form name is going to be the namespace, sort of the path of your endpoint. And then on that form, you’re going to create specifically named methods. So W as read, the translate to a GET, and will handle any GET requests on that form name. And a write is a POST, and the update is put, and the lead is due to the lead. So you get all the cross functions, are available there. Any other methods that actually exist are not supported, I don’t think so. So you got a function then for POST, so the W is write, use the plugin, the REST WS plugin to get its requests, body is actually, or the other request, and then you get the contents of that, and then you have all that request. I actually didn’t find a lot of documentation about that. So looking at server again, how to really work with that. I don’t really use the REST WS plugin I use, the other thing that I’m going to talk about. Now it’s this, but so then you access that endpoint by an interesting URL here. So your host name, report number of your soy instance, and then the soy servers, slash REST on a score WS, and then you need to also make sure the solution name where it form is located, and then the form name. So you probably want to put a reverse proxy in front of that, where you have a nice logical name that actually maps anything that’s behind that custom URL that you have to do to make, and maps it to this, and then anything behind the solution and will then be sort of passed, essentially. Because the form name is part of the path or your endpoint. So you should not put that in your reverse proxy that should come from the request. The other way of doing things is the default sleep login, but if you have a lot of flexibility, it’s available on the server forage, open source plugin. It’s based on multiple libraries, including the Apache velocity, which is an Apache project from the Apache Foundation. And the full sleep login is really three plugins in one, that started out as a reporting plugin, and it’s the name full velocity report. And then it, Patrick Tobo wrote this, and effectively implemented the whole REST and web page, servering, servicing functionality, and then the third plugin is actually you can use full sleep to actually consume other APIs. There’s a way of doing that, sort of create an interface within your solution, so you can use that sort of the Savoy way without writing a lot of code using the HTTP plugin. So with full velocity, you only have one point of entry, and that is like the Canviano form can be on the global scope even, which is the VR, VR, as it’s plus report, get context. And as arguments, you get a request object. And so the request object holds a ton of information already. So if you say request on method, then you can see how that endpoint was called, was it a get, was it a post, was it a delete, was it a head, option or a tracer or patch, those are all methods that are available with an HTTP goal. You need to have their own meaning really. There are also some musical collections that you can use, so you can get the cookies there are being passed on as well. All the headers, any sessions, if you have a session based solution, so your instance is that a session, there are user groups also request parts if you get a multi part post, some data and maybe some binary as well, in your request point. Then it works with parts. There are also single values. All of the information is available that you don’t have to collect it somewhere that’s just being passed in the request object. So path involved protocol, so it’s Dights BHBS, was there anything behind the question mark for query string, which form was requested, et cetera, et cetera. So very extensive. So then you get something like this, the VRGIT context, find a response of the act. In this case, I don’t even look at what the path was. This is completely just the example. I call a method and get a response back, and I simply say, okay, create a response, and return that. That’s really what it’s about. Get the request, if it’s opposed, put the lead, whatever, do you think? Come back with a response, and then return that response, or turn it into response object, and then return that stuff. So in this case, I’ve got a tried catch error. This simply creates actually, I could create an error response from this case, a create a normal error response, put in a JavaScript object with one property error, and put in the exception. That’s a bit of a deep up info. Very simple example. You can make this as elaborate if you want. So, and then the way you call this is pretty much something. It’s a voice service slash velocity in this case, because it’s a different service. Also the solution name, so which solution, the code is in, and then the namespace. So I call this a namespace because velocity works with a config.json, where you can provide some mapping to specific forms. So in this case, config.json, it’s a JSON file, where you say, okay, solution name, we say, okay, I’m using a pool of license instead of session base. So like the specific, we say, okay, I wanna have all the requests on by a pool of in this case, five clients. And if you get more, if there are more requests coming in, then it actually blocks it, it’s the collection, and also on all my nulls, we see your lives. So there are many, many, many other options that you put it in. But what’s important here is the pages. So pages you can say, okay, the path API should be mapped to my form my API. So API is the namespace, but it will be mapped to your form inside your solution, which I call my API. And you might have another path called doc, it goes to my doc, and then you can say asterisks for, okay, anything else that will go to my everything else for, or you leave it out in the synthesis, okay, four or four, and then send that a file, if I don’t know. So that’s how full of your works. So here, the namespace maps to these API doc, whatever. All right, so let’s building your API. There’s some best practices when you creating those paths of your endpoint, and that is, use nodes to represent a resource. So, nouns are exactly things. Like clients, orders, and then also use the plural form. So not to client, add order. Unless it’s a single. So you say, okay, I wanna customize or it’s stats. If status only returns one thing and one thing only, that’s a single thing. So you’re not gonna say, okay, slash status, because they don’t sense. This by the way, also good practice for like tail names, because you collect more than one role usually, so it should be plural form. Also keep the naming consistent over all the end points. So if you talk about a customer here, and then a client there, and they mean the same thing, that’s inconsistent. So name both client or both customers. And if there’s some hierarchy, then use the forward slash to, to get it. That hierarchy in this example, you got customers, customer ID, and then the orders of that customer. Right? So then that’s an immediate filter on the orders. But don’t necessarily, you’re in this example, customers, orders, and any enforce is just all those orders. That’s, that’s, it gets confusing really quick. So you really should use customers ID orders, and then you get a list with order IDs usually, and then you can fetch the invoices per order on a different endpoint. So that’s usually the best practice. Also use hyphens to increase the readability in the URL. So, so if you get like two words, media devices or whatever, then don’t make it one word, but do an knife in between. So it’s more readable, especially if it is our longer names, one words. And also don’t use on the scores, because that makes it really unreadable. As an aside with the rest WS plugin, the namespace, so force, you can’t use hyphens in an in a format. So there you have to use on scores. So that will translate to your URL. So that’s, that goes against the best practices. Also, never put, put function names, functions in the names, like get customers, update customers, simply use the customers endpoint, and then use the method to, to say what you want, right, post get with the link, etc. And if you need to filter something, then you usually use the query parameters, which is anything behind question. So we say, okay, give me all the customers where the name is. So for. Also, don’t use verbs like executing your URL, that’s really an RPC. So, the remote procedural, got what’s the list. Yeah, call, yeah, call, you have remote, see your poll, exactly, yeah. Which is not rest, so don’t use that. Okay, so now you have built your, your REST API, you do using all the best practices. You should document your API, because we wanted to publish our API, right? Everybody should be using our product. So yeah, there are several ways of documenting your API. You can simply write a PDF or Word document and type it all out or you can do it a standard way. Over the years, I have in couple standards, which is the web services definition language, WSDL or Wistles, let’s say, try to name it. It’s an XML based documentation done by the VM Microsoft and SAP. And then you had well, web application definition language, which was done by some microservices, so again, XML based. And then Sraitor came onto the stage and they created a JSON based description, which was done by SmartBear. Actually, it was Wooknik, I think before that, but, and then later, open API came and actually open API, actually, what SmartBear did was give the Sraitor specification to the Linux Foundation and the Linux Foundation created the open API initiative and the Sraitor spec came open API to point out, because Sraitor was at that point, in version 2.0. So all the Sraitor specifications are now open API specifications. And open API is JSON and XML based specification. So if we look at the timeline, then in 2000, you had the Wistle specification and then in 2009, the Waddle, some microsystem. Then 2010 was Sraitor was founded in 2014, they already had the Sraitor 2.0 specification. Then in 2015, they gave it to the Linux Foundation. And in 2017, we had a new, new-to-created specification from, effectively, the Sraitor 2.0 and then came open API 3.1, 3.0, sorry. And then in 2021, so two years ago, we had the open API 3.1. So Sraitor, that’s almost nine years old. Sraitor 2.0, Sraitor 2.0, Sraitor 2.0, NAPI 3 is now five years old, six, sorry. So yeah, that’s sort of the new way and look at the open API initiative, it’s an open governance structure, like I said on the Linux Foundation. Many, many, many companies are part of that foundation. It’s a vendor neutral specification. Like I said, it’s based on Sraitor 2.0 spec. And it’s based on open standard, like JSON, but also JSON schema, et cetera, et cetera. So in those schemas, we’re going to understand it’s also changed and all those changes get then also re-implemented in like newer versions of open API. They’re already working on an update of JSON schema, spec in like 3.2 version of open API. So these are all the people, all the vendors behind the open API specification. Really big companies, yeah, that. And if we look at these five, these are companies behind the specifications, the wisdom, the wattle, et cetera, and smart bear from Swagger. So all those companies are backing open API. So you could say that open API is now the de facto standard for describing REST APIs. And there are a ton of tools that work with open API in specification, auto-generators, over-vers, validators, their editors as well. So they’re mock servers, so you can think you put in any code. And you can simply start querying against those endpoints. You’ll get some mock data back automatically. So you can start writing client code to tessell that parser, et cetera. So there’s a ton of tooling available around this specification. All right, well, should we code first or should we design first? So there are two approaches here. So let’s look at the code first approach. Let’s say the REST and WS plugin, Savoy created a module, this is why API module, which is available on the Savoy package manager. And it’s an API doc generator. And it works with the annotations in the J’s doc header of your methods. So the WS read, right, et cetera. So you have to define it in the J’s doc. And then it will look something like this. All right, you get a WS read with a pet ID and you code in there, but you have to describe it all. So summary, the pram, it returns something. And if it returns 400 and it returns 404 and what are the whole things and stuff. So that’s being used by the module effectively sort of parsing your code to create a swagger 2.0 specification that looks something like this. So that’s code first. You code, you create a code for which you document then also in your J’s doc. And then it generates this specification for your documentation, which can be used in other tools like documentation, viewers like Swagger UI or Postman as a client tool. So you can start querying your API yourself, et cetera, et cetera. So all that is all those tools can use this specification. So this is a Swagger 2.0, so that’s a nine years old spec. Or you can take the design first. So you’re first gonna write your specification. So why would you do that? Because you can easily involve all the stakeholders and write it like John set with designing the UI. If you simply do it in that, in the text detail, you can get a lot of stakeholders involved. Before you even write a single code or put a single element for the same thing here. Changing the spec is way cheaper than coding when the zone. So, according to the API, also becomes a well-easier because you just follow your documentation, you already expected out. This is how it should be. This is how it should look. And you simply have to write your code and that’s it, according to your specification. Like I said, the tools allow you to use a mock server when designing all of a sudden. And there are also tools to generate code steps for applying the server, although for supply. That’s not really many other languages. It can generate code for you, which you then use to continue on essentially. So the all-and-down site is that if you change the spec, then you cannot regenerate because it all writes all you go. Raise new fonts. You do all this from a single source of truth. Your specification is fake. So this is the specification that you can look at to find out this API. And it’s very extensive. You can describe pretty much anything, which is also a thing like if you do the code first approach, you are able to code something that you cannot describe using the API specification. So then your code yourself at the corner, that’s it, right? Because if you cannot tell someone how to use that API, then let’s use that API. And to have a way of describing that API to solve. So if we look at sort of the general structure of the API, you got a couple of blocks because open API, the specification is really like a hierarchy. These are top notes, if you will. You got the info note, dose, note, text, note security, pass, those are your paths, you read your end points. External docs and components. Components is an interesting one. I will show you later. But let’s look at the info, simple that contains a title component, a description, contact information, license information, version, terms of service. So all that is part of your documentation and also can be seen on any data page or your tools. So all you can see the information. Same thing with the contact. You can have your email, there’s a there, your URL, etc, etc. It’s part of the specification. So I’m gonna skip over the other ones, pass is where all your end points are being defined. But if you get a lot of end points, then you notice that you have to repeat yourself a lot of times because if you do a post of a customer or you do an update, put up a post- the parameters that you have maybe in the URL, in the queries, etc. Any specific headers that you have defined, you can just put it there and reuse that reference that in all the end points. The request body links examples, callbacks, any schemas. Let me show you how it looks like. So I’m gonna go here, let’s let it’s here. So here I have the swagger editor. The swagger, so smart bread gave away their specification, they’re still a tooling company. So they got regular UI, swagger editor, still named swagger. So sometimes that’s confusing. People say, I’ve got a year of swagger, but it’s specification, but then it actually open API, especially if it’s 3.0 and higher. But as you can see here, I hope you can see it. This is a started 2.0, which is an example of, but let’s convert this. Do I open API 3.0? And now it’s a 3.01 specification. As you can see here on the right, it also says this is open API specification 3.0. S3. And here you got all the end points, certified. So this is sort of a preview, the way swagger UI would look like. So you can go here to put, you click on it, you see what the request body would look like, which is JSON and then you can see what all the responses would be. That’s empty with a post. Here’s the specified, so it specifies what the structure should be, what the field names, the property name should be, what types they are. And if they’re required or not, so we go to a schema here, then here you have all that specified. And this is an enum, so you can only have these values. So you’re dividing exactly what you’re expecting from that end point. So anyone who’s consuming that end point in those exactly what should be put in there. This editor is, it’s an interesting editor. I can do proper, a yellow formatting. So here we got the info block, external docs, the service tags, and tags are being used by the way on the end points here. So this is a tag, this is another tag. And so you can put the tags on the end points and group them together. So look until likes where the UI will show them to get. And then here you go, the schemas that are defined. So here I can collapse this, by the way, this is just a web browser. This is an editor in a web browser. Very capable editor. I don’t know, I might have had that. So here you got all the end points, and the collapse all this, and look, see what’s going on here. So here we got components, schemas, and scooter schemas. Here we got the paths and tags to service, collapse as well, collapse, collapse. This is the structure of your open API specification. So here we got a path with a put. So this combination makes it an endpoint. So this is how this endpoint is being used. Here we got a reference to a shared component, which is schema. And also says, okay, you can get it as JSON, and you can get it as an XML, but it’s the same schema. It’s just a different format, right? And we look at the schemas here, you can see type object, program has properties ID, pet ID, quantity, exactly say what it is. For example, here we got a shift date. So type of string, everything is being sent, pretty much as a string, or a number in integer. And now you say it’s the format, daytime. Right, so you tell the developer that consumes API, I’m expecting daytime according to a specific format. So finally, I have that here. This is the order. Oh, here’s the data. Yeah. Usually the examples shows exactly what your order post. This is sort of the format. If you say, okay, it should be a format date, then you get a date dash, month dash here, et cetera. So that’s all being specified here. You can specify really like it should be, is the required thing. I don’t think they have that specified here, but oh here, here we got the wide one. So from this object, these two properties are required. So they should always be there, if you do a poster or put. So it gives you a feel of how this should look like and structure and all the properties that you can put in there, which is a lot. So let’s go back for a moment and talk about what you can do after this. Because now you have specified all those constraints, how it should look like, what is required, what data types? You tell the whole scheme, I essentially what you’re required. And since we cannot generate any code stops, but would it be nice if we still could use all that information that we wrote down to use that as code. And I thought of that pretty hard and I came up with this, raw. Raw is the, the last you open API rod. Yeah, that would, I mean, I maybe the first open API rod ever and then it like, it doesn’t make for a nice short name. So the art, the art in front of it. So, raw. It’s a Savoy module. It’s designed to work with the false plug-in and also with the opening guide plug-in that’s also Patrick Cruz for me, which is also based on the Swagger libraries that is available, the Swagger source of pretty much all its code, which is nice. And what it does, it uses your open API spec to map it to your methods. So your endpoints are defined in your code. And it comes in at your via get context and then it gets mapped to your other methods. And on top of that, there’s all the validations that you have defined already in your specification. So you don’t have to, right? Before it reaches your code, it’s already validated. If it’s invalid, but you don’t have to do anything, the framework already can get it back way to 400, like sorry, this is not good. And takes care of all the repetitive stuff that you can, so you can focus on your field. This is real. So here we got paths. So here we got the pets from the pet store, path and with the two endpoints, they can get and the posts and both get an operation ID, which is part of the open API specification. It’s not a custom property here. So I’m sorry, operation ID. It’s an identifier. So that means it has to be unique within your specification. So here I have pets.get, pet store posts, because that’s on the post that you get. And I’m using the periods here. So I can, because you can simply use it just along the main. But if you use periods here, then raw will look at the operations map in a hierarchical way. So you can do this. So here we got the operations map, just just an object. Pets.get the posts, right? And then you got your method of reference on those properties. So that’s the map. So this, these operation IDs get mapped to these methods. And then you put in another variable here where you use the loaded open API file. You pass the operations map and you tell where the file name, which looks into the false report for because you pass the operations map with them. Then it develops also like, are there missing operations IDs in your spec? Are there missing functions in your operations map because their operations ID that haven’t been mapped? So all that to keep your code and your documentation in sick. So it’s there to help you. And then you get a method like this where you say, okay, I need to, so we’re gonna pass a context, which is JavaScript object. So that’s always done by reference. So you’re not throwing data all the time and you can put data into that context, into that object and use it here. So we have a standard context that we need. So we use the sculpt open API create context. We pass the request, that request will be part of the context as well. And then context.response is sort of a custom property that you might wanna add or anything else that you wanna add to the context to be passed around and be used in your methods. And then the only call you do is scopes API, open API dot router where you pass the spec, the operations map and the context. That’s it. It does all the validation. If it’s not valid, it returns it. If it’s, if it, someone tries to call an endpoint, it doesn’t exist. Maybe you get four back that tries to use a method on a path that doesn’t exist. They wanna do a delete on that such paths and does not allow those. You didn’t specify that. So that’s a four or five method, it’s not allowed. Or not supported if they do an option skull. Like that’s part of the entity method, right? Give me the options of this, this path. That returns all the possible methods of that specification. Does all that for you? Validates all your, like if there is a request for the, is it valid? And then passes on to your method, like here, for example, you should repeat a method, you get context, you do your business logic, you put in your response, you don’t have to return anything because it’s by reference variable. So at the end of the method, then it goes back here. And then you say, just to make it fit on the slide, put it in a shorter variable. But the response, you create the response, you return your response, that’s it, done. Very simple, because you did all the work, right? So why would you repeat yourself? It’s gonna be available at the end of the year. It’s gonna be open source and I’m gonna put it up for a forch that’s already pretty far, using it in a couple of projects, but there’s still some work to do to get all those validations in the vocabulary of the open API in there. So, but it’s coming. Any questions? Good evening, Mike. And so how would you use your, this what you just showed, actually speaking to Savoy to action your API? How would you use that? It’s the same way you would use a full city report. So the full city plugin. So it’s effectively a library that you use with the full plugin. So you create your config to JSON with your solution, your path, pages. You say, okay, API goes to this form and this feeder get context. And then any path of your endpoints, or your endpoints essentially are being passed to this open API don’t router. And that’s it. And that get mapped to the operations map and those methods will turn out the code. And so the benefit is that all those methods don’t have to do all the validating and expecting. It’s like, is there a value? Because it’s a required value. That sort of thing. So because you’re specifying that already in specification, then the open API router will validate that. And if they don’t pass that required fields, that won’t hit your method. It’s already being returned to color. It’s like code 400 in the, or you’re missing these specific fields. It will specify that actually. So it provides also a lot of deep looking information for the consumer or the right field, based on your specification. So this only works if you are a full-state report. What if you’re on breast, be a REST plugin by Sephoy, what that is that going to work? It’s possible to do. This is not our work with the REST, with the REST WS plugin. Because that’s every, every method is an endpoint. And don’t think you even get past. I mean, I really don’t use it. So the flow city gives me way more flexibility, more control, control, free, I love it. This so it gives me all the information, especially in the request of the act. Everything is in there. And so yeah, so this is really designed to work with most. Okay, thanks. Sure. And I understand that your core plugin is not going to work with REST WS. The opening API plugin, does that, is that independent of velocity? Or is that dependent on velocity as well? No, open API plugin is really just a way of reading. The YAML or JSON, it also be just files and turn it into a JavaScript or text so you can use it in your code. So the thing is a representation in your JavaScript. So the open API plugin doesn’t do the validation to your bits that does the validation and rejects the request prior to that. That’s really the sort of my code in the module. So the open API plugin is really to just to read the specification file. Okay, thank you. So it’s part question about use authentication in API. We could use the WS authentication outed gate for that. But then you only have base authentication in that, how about if I want to use bare token? And the thing that Patrick viewed the velocity also has support for that word. I mean, bare authentication, pretty much all the of the authentication are part of the header. All right, so all that information is in the request of yet. And then your code can use that to act according. So any tokens, any basic authentication, all that information is passed to the request of yet. And then you can write code for that to handle that and then say you’re not allowed to be wrong. So that’s really, I mean, it gives you a lot of free exactly. It’s not like really frameworks, like this is how you have to do it. It’s like, here’s all the information. That’s it. And if you want to create a response, then you call function. Not grace response, then put it in the header, just the cookies, whatever. You can do all that custom headers. That’s what you really want to for mostly plugin does for you. Yeah, because well, I understand. And this is good that we have the freedom to do that. But yeah, we do that there using the, not using the velocity, but using just a white, no, so far behind it. And I was just expecting something like the WSP gate that supported that white self. But anyways, you have to, you have to, to create a function and we use that to process the request. They’re talking that is coming with the request, right? So, you know, I was, any of it is, well, I’m just a smaller question for those of what people then I don’t know if that’s a question for now, but if this is going to be supported in the future. Any other authentication? I mean, any authentication is in the end, web rest. And I know that the rest WS plugin has sort of a way to say, well, any authentication things will go to specific method. Again, that’s frameworks like previously helped it, this name. And I’m sort of wanna do something the same thing in my API router where I can add a fourth parameter. So that’s okay. Any security, any authentication or any endpoint that has security defined on the endpoint, your specification will get passed to that method where you then handle it according. Because the open API router collects a lot of information already for you, puts it in the context in a structured way, like which path it is, the security things and time is up, we see. And provided to the methods, so you can use that in the end, you can also see use for logging, which is probably something that I would strongly advise. Log everything that comes in and out. Because you have no visibility on what’s going on on your API system. Log everything. Yep, we have to land it. Yeah? Thank you very much, gentlemen. Over to you. APPLAUSE MUSIC