I'm looking for a way to execute some filters and predicates on a request, and at the end simply return a response to the user, instead of routing it to a specific URI.
For example, a user is calling /auth/token and my gateway has a filter that generates a token and transforms the body of the response (using the ModifyResponseBodyGatewayFilterFactory).
When adding a filter that simply returns response.setCompleted(), the body returns empty and the status code is always 200.
return (exchange, chain) -> {
return modifyResponseBodyGatewayFilterFactory.apply(c -> c.setRewriteFunction(Object.class, String.class, SomeBody))
.filter(exchange, chain)
.then(exchange.getResponse().setComplete());
}
How can I return a specific body to the user, without routing to a URI?
Thanks in advance!
I couldn't find a solution, so instead, I've created a web flux controller for this specific request.
This is a good enough solution for me.
Related
We had a spring web-app that used to handle all front and back end logic. As we need to scale we have split that into two microservices. How would I go about 'forwarding' a post request to another url (including its body and authentication headers). For example:
microservice1 has an endpoint /api/doSomething
microservice2 has an endpoint /privateUrl/doSomething
I want the user to hit the endpoint on microservice1 which will post to microservice2 and return the result.
I have tried with RestTemplate without much luck, i keep getting error "Could not write JSON: No serializer found for class..." from microservice1, i suspect this is because microservice1 doesnt know how to parse the body object microservice2 requires.
microservice1:
#PostMapping("/api/DoSomething")
fun postIT(request: HttpServletRequest, #PathVariable one: String, #PathVariable two: String){ ...}
microservice2:
#CrossOrigin
#PostMapping("/privateUrl/doSomething")
fun postIT(request: HttpServletRequest, #RequestParam one: String, #RequestParam(required = false, defaultValue = "true") two: String,#RequestBody it: IT) { ... }
I know i can parse the entire request in microservice1 and then send it to microservice2, however is there a way to just 'forward' the http request to a new url?
I am not sure what you mean , but if you want to communicate from one server to another you can always use rest template (or any other) and send http request from one service to another, you can see examples here
https://www.tutorialspoint.com/spring_boot/spring_boot_rest_template.htm
https://spring.io/guides/tutorials/bookmarks/
take a look it should work for you.
Using POSTMANto call an endpoint for example:
http://localhost/v1
Checking Request Method in the code using:
context.getRequest().getMethod()
No matter what I change request method in postman request, I always get the first request method I select let say GET.
When i change request to
http://localhost/v1/
It works and start sending correct request methods i select in POSTMAN
http://localhost/v1
I am expecting that when I call:
http://localhost/v1
or
http://localhost/v1/
It should behave same way.
Any explanation to point to the right direction would be appreciated
you need to redirect /v1 to /v1/ try like
#RequestMapping(value="/v1")
public ModelAndView redirectToPage() {
return new ModelAndView("redirect:/v1/");
}
On the retrieve code below, how to get Person instead of Mono or how to get Person from Mono, please ?
23.2.3 Request and Response Body Conversion
The response body can be one of the following:
Account — serialize without blocking the given Account; implies a synchronous, non-blocking controller method.
1.7.1. Retrieve
WebClient client = WebClient.create("http://example.org");
Mono<Person> result = client.get()
.uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
.retrieve()
.bodyToMono(Person.class);
Once you have a Mono<Person> instance available, you have two choices:
compose that reactive type (i.e. use operators available on that type) and use it to save that data in a datastore, serve it as a HTTP response body, etc
or call Person person = result.block() on it, which blocks. So you should not do that in a reactive application because this might completely block the few threads available to your application.
I have such a route in my routes/web.php
Route::resource('/api/surveys', 'SurveyController');
As documentation says, it creates all needed routes for API. This is a function, that gets executed when I go for /api/surveys route:
public function index()
{
$request = request();
if(!$request->hasHeader('token')) {
return "No auth token found.";
}
$tokenCheck = $this->userService->isTokenValid($request->header('token'));
if($tokenCheck !== true) {
return $tokenCheck;
}
return $this->surveyService->all();
}
What it does, it checks if token header parameter is set, if not, it returns an error, if yes, it checks if token is valid and etc. if everything is OK, it should return surveys from database.
public function surveys() {
$request = \Request::create('/api/surveys', 'GET');
$request->headers->set('Accept', 'application/json');
$request->headers->set('token', \Cookie::get('token'));
$response = \Route::dispatch($request);
print_r('<pre>');
print_r($response);
print_r('</pre>');
}
I have a website, that should use that API I just created to get all survey records. I create a new request object, set header "token" with token I get from a cookie and then try to dispatch and get a response. But the problem is that everytime I get "No auth token found." error. That means $request->hasHeader('token') returns false, even tough I set it here in my request. If I print_r $request->all() in Restful controller, I get an empty array.
I tried Postman to access this API with token parameter, and it works fine in postman, but here, it seems that Request disappears while it travels to API controller.
What I did wrong here?
When you manually create a request and dispatch it, that works to get the routing to call the correct controller, however that does not affect the request that is bound in the container.
When your "fake" request is handled by the api controller, the request that it pulls out of the container is the original "real" request that was made by the user.
Instead of dispatching the route with your new request, you will need to app()->handle($request) the new request. This, however, will completely replace the original "real" request with your new "fake" request, so everything from the original request will be lost.
Having said all that, this method of consuming your own api is discouraged, even by Taylor. You can read his comment on this Github issue. So, consuming your own api like this may work, but you may also run into some other unforeseen issues.
The more appropriate solution would be to extract out the logic called by the api routes to another class, and then call that extracted logic from both your api routes and your web routes.
My existing code is like:
String myController(#PathVariable someId, ModelMap map){
....
return "myViewName";
}
Now I want to set a cookie in some cases, so I need to get hold of a HttpServletResponse obj. Can I just add such a response obj to the list of params and operate on it in the controller?
If so, I wonder how my own response is kind of reconciled with the response generated by the JSP that resolves the "myViewName".
Yes.
#RequestMapping
public String myController(#PathVariable someId, ModelMap map, HttpServletResponse response) {
// Do what you need to do on the response, like set a cookie
return "myViewName";
}
Regarding your other question : "how my own response is kind of reconciled with the response generated by the JSP that resolves the "myViewName"."
When you return a view say "myViewName", it will be resolved to a particular resource (JSP View or JSON View or any other view). Once that view resource is obtained depending on what you return, that view does the rendering on to the response. This response object is the same that was passed to the controller function (myController). So say if you set some cookie/headers on the response in the controller function, the response that is being used by the view to do the rendering will also have the same properties.
In case you want to handle the actual rendering/response yourself, you can always get the outputstream of the response and write to it and close the stream. Then the view that you return is just ignored as the dispatcher will check that the response is already handled and will just do post handle stuff.
Hope that clears up for anyone looking for the dispatcher logic behind it.