We are using the latest Docker images of Business Central and KIE-server, and are interacting with the rules service client using KIE's REST API.
We created a set of rules in Business Central that, when fired, insert a "Response" fact.
We would like to be able to sent requests to KIE Server in a stateless manner; i.e. every time we send a request (typically composed of a chain the following chain of commands: insert-object -> fire-all-rules -> get-objects) to the server, no objects/facts from a previous requests should be returned by the get-objects command.
From what we understand, one way to go about this would be to create a new session for each request. How would one do that?
Any other suggestions and/or references?
Stateless API calls will work once a stateless session is defined. In your API call, refer to the stateless session using the "lookup" key.
Here is a reference to another StackOverflow which explains how to create the stateless session in Businsess Central: How to invoke decision service as a stateless session in Kie (RedHat Decision Manager)
Related
I have implemented REST APIs (GET and POST), my concern is regarding the stateless part of the REST API standard. This is how the APIs are accessed:
The client logs into the application which is hosted on a web portal. The web portal authorizes the logged in user and adds a identifier in the request.
When a request is made to REST API, a filter implemented within the application checks whether the incoming http request header has an identifier associated with it (added by web portal while authorizing).
If header has identifier associated with it, filter passes the request towards the controller.
It would be appreciable if someone could verify whether this design is in accordance with REST stateless principle.
Stateless, in the context of REST, has a very specific meaning
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
The classic case of session state leaking into HTTP requests is the use of Cookies.
I don't see anything in your description that leads me to think you are using session context here.
Question
Can I get nginx to call another microservice inside of AKS k8s prior to it routing to the requested api? - the goal being to speed up requests (fewer hops) and simplify build and deployment (fewer services).
Explanation
In our currently deployed Azure AKS (Kubernetes) cluster, we have an additional service I was hoping to replace with nginx. It's a routing microservice that calls out to a identity API prior to doing the routing.
The reason is a common one I'd imagine, we recieve some kind of authentication token via some pre-defined header(s) (the standard Authorization header, or sometimes some bespoke ones used for debug tokens, and impersonation), we call from the routing API into the identity API with those pre-defined headers and get a user identity object in return.
We then pass on this basic user identity object into the microservices so they have quick and easy access to the user and roles.
A brief explanation would be:
Nginx receives a request, off-loads SSL and route to the requested service.
Routing API takes the authorization headers and makes a call to the Identity API.
Identity API validations the authorization information and returns either an authorization error (when auth fails), or a serialized user identity object.
Router API either returns there and then, for failure, or routes to the requested microservice (by cracking the request path), and attaches the user identity object as a header.
Requested microservice can then turn that user identity object into a Claims Principal in the case of .NET Core for example.
There are obviously options for merging the Router.API and the UserIdentity.API, but keeping the separation of concerns seems like a better move. I'd just to remove the Route.API, in-order to maintain that separation, but get nginx to do that work for me.
ProxyKit (https://github.com/damianh/ProxyKit) could be a good alternative to nginx - it allows you to easily add custom logic to certain requests (for example I lookup API keys based on a tenant in URL) and you can cache the responses using CacheCow (see a recipe in ProxyKit source)
For browser based request with sticky session true load balancer can restrict request to same JVM out of multiple JVMs in a cluster.
But in case request is coming from REST client rather any browser, how the load balancer can restrict requests to same JVM even sticky session is set as true? Any Idea please.
REST client is made to call REST API and REST APIs should be stateless i.e. complete information about processing of request should be present in request itself, thus request should not dependent on any session data.
If your API is dependent on session data then in actual it is not following some principles of REST.
If your requirement is such that you need to maintain the state then it should be maintained on client side not on server. So one of the way that i will suggest is that you can use cookies to store your state and temp data. While making any REST api call just attach that cookie with request.
You can make cookie configurable so that it will be controlled by server and no one else can make change in it.
The load balancer uses Cookies to keep track of sessions. Retaining the cookies and sending them back in the client should be enough to get the expected result.
For instance, in python, that would mean replacing requests.get(url) with:
s = requests.session()
// ...
s.get(url)
I currently have:
a REST API (Jersey) that runs as a seperate application
a GUI application (JSF) that is a client of the REST API
I'm wondering what the best way is to talk to the REST API from the GUI application. The REST API is stateless, but the GUI application is stateful and has to pass authentication info (basic auth) with every rest request. Because we have to support hundreds of simultaneous users, we want to configure our Jersey client for connection pooling.
We can handle connection pooling by configuring the Jersey client with Apache's HTTP client. Authentication can be handled by using the HTTPBasicAuthFilter, which will automatically send the same credentials with every request.
However, I'm not sure if it is best to configure 1 client for the entire GUI application, or to create a new client per session.
With 1 client for the application, connection pooling makes sense, but then I have to find a way to set the correct authentication info on every request. The HTTPBasicAuthFilter assumes that the credentials never change, which is not the case our app.
If I create a client with a new HTTPBasicAuthFilter per session, then authentication is trivial, but I don't get any benefit from connection pooling, since every client will have its own pool.
I doubt I'm the first one to run into this, so I am curious how other people have solved this.
Kind regards,
Glenn
You can attach client filters at the WebResource level. So you can have a single shared client and per-session WebResource objects that you attach the HTTPBasicAuthFilter to.
I have a COTS application(PLM application) which has provided few SOAP APIs to access. Since this SOAP API is highly complex, we are developing a easy to use REST wrapper service. Before invoking any API in my COTS application, authentication API needs to be invoked. In my REST wrapper web service, I have a login resource which invokes COTS SOAP login API. To keep things simple for my API users, I store the logged in user details in user session. In every other REST resoruces, I retrieve the session and check whether session has user details. If yes, I proceed and invoke the SOAP API. if not, I return proper HTTP status code. I use Apache CXF for service and client. I mandate my APIusers to maintain the session in the client like this
WebClient.getConfig(client).getRequestContext().put(Message.MAINTAIN_SESSION,
Boolean.TRUE);
In every REST tutorials, it said REST is stateless. I am doubtful whether what I am doing is correct as per REST standards. Please suggest. Thanks
Basically the idea of REST is a stateless interface. However it is common practice to use some kind of authentication for API calls since most of the time not all resources should be public (e.g. the timeline of a twitter user over the twitter API)
Therefore it is ok if you do some kind of authentication and validate a session on further requests (or maybe authenticate with every single request, e.g. with HTTP Basic Access Authentication) to check if access should be granted.
Not part of this and not the idea of a RESTful API would be to store complex session information that would really make the whole thing stateful. This for example includes storage of information of an older request for processing together with one following later.
client.getRequestContext().put(Message.MAINTAIN_SESSION, Boolean.TRUE)
This code causes cookies to be maintained in that specific client only.
If you want those cookies be available in another client, it needs to be programmed.
And if the second client receives additional cookies and you want those cookies available in the first client too, how is that possible?
I need something like a root client that maintains cookies of all sub clients. All cookies must be shared among all clients. Like a shared cookie repository for all clients. Does anyone know how to achieve this?