Actually what does the restTemplate.exchange() method do?
#RequestMapping(value = "/getphoto", method = RequestMethod.GET)
public void getPhoto(#RequestParam("id") Long id, HttpServletResponse response) {
logger.debug("Retrieve photo with id: " + id);
// Prepare acceptable media type
List<MediaType> acceptableMediaTypes = new ArrayList<MediaType>();
acceptableMediaTypes.add(MediaType.IMAGE_JPEG);
// Prepare header
HttpHeaders headers = new HttpHeaders();
headers.setAccept(acceptableMediaTypes);
HttpEntity<String> entity = new HttpEntity<String>(headers);
// Send the request as GET
ResponseEntity<byte[]> result =
restTemplate.exchange("http://localhost:7070/spring-rest-provider/krams/person/{id}",
HttpMethod.GET, entity, byte[].class, id);
// Display the image
Writer.write(response, result.getBody());
}
The method documentation is pretty straightforward:
Execute the HTTP method to the given URI template, writing the given request entity to the request, and returns the response as ResponseEntity.
URI Template variables are expanded using the given URI variables, if any.
Consider the following code extracted from your own question:
ResponseEntity<byte[]> result =
restTemplate.exchange("http://localhost:7070/spring-rest-provider/krams/person/{id}",
HttpMethod.GET, entity, byte[].class, id);
We have the following:
A GET request will be performed to the given URL sending the HTTP headers that are wrapped in the HttpEntity instance.
The given URL contains a template variable ({id}). It will be replaced with the value given in the last method parameter (id).
The response entity will be returned​ as a byte[] wrapped into a ResponseEntity instance.
TL;DR: Q: What is a request-response pair called? A: An "exchange".
The term exchange is used, almost incidentally, in the official technical documentation of HTTP to refer to an HTTP request combined with the corresponding response.
However looking at the answers to the following questions, it is clear that while this may have represented a de facto standard for some people, many other were not aware of it, or hadn't adopted it.
What is a request-response pair called?
Name for HTTP Request+Response
The documentation doesn't bother to mention the etymology of the name -- probably assuming that it's obvious.
Notice, however, that there are many different RestTemplate HTTP request methods listed and only a small fraction of them are named exchange. The list is primarily made up of HTTP method-specific names such as delete, put, getForEntity, postForObject, et cetera. Technically speaking, all of these methods perform exchanges in the same sense, but the more focused convenience methods are limited to a specific subset of the possible exchange functionality and parameter+return types.
To put it simply, the set of exchange functions are the most general/capable methods provided by RestTemplate, so you can use exchange when none of the other methods provides a complete enough parameter set to meet your needs.
For example:
Sending GET request with Authentication headers using restTemplate, in which the OP has noticed that "...the only way to send Headers such as accept and Authorization is by using the exchange method..."
The more generic exchange API requires a HttpMethod parameter and a request object for completeness. Compare:
ResponseEntity<Foo> response =
restTemplate.exchange(url, HttpMethod.GET, request, Foo.class);
ResponseEntity<Foo> response =
restTemplate.getForEntity(url, Foo.class);
The exchange method executes the HTTP method against the specified URI template, passing in the parameters for replacement. In this case it gets an image for a person entity for its Id parameter and returns the byte array for it.
Related
I am using JsonServiceClient in a Xamarin app, like this:
JsonServiceClient client = new JsonServiceClient("https://my.domain.com/");
SetHeaders(client);
var request = ...; // this is IRequest<T>
var result = await client.SendAsync(request); // <-- FAILS, can't find service
My backend returns an answer, saying that there is no service at that endpoint, which is true, the path that was actually sent over the wire is incorrect.
The request is defined in a lib, like so:
[Route("/mybasepath/endpoint", "POST")]
public class Login : IReturn<LoginResponse>
{
}
The problem is the path that is used in the call, which is wrong and does not follow the Route attribute:
https://my.domain.com/json/reply/Login
Here, ServiceStack client uses the default /json/reply path, even though I have the Route attribute defined in the DTO.
If I change the method used on the client instance, and instead use PostAsync, the path is ten correct and the call work as expected:
JsonServiceClient client = new JsonServiceClient("https://my.domain.com/");
SetHeaders(client);
var request = ...; // this is IRequest<T>
var result = await client.PostAsync(request); // <-- WORKS!
I don't have a minimal project right now that can be immediately tested, maybe it is something easy I have missed?
(Using ServiceStack.Client v 5.10.4 on VS 2019 16.9)
If you want to use ServiceStack's generic Send* APIs the Service Clients needs to explicitly infer the Verb to use by annotating the Request DTO with an HTTP Verb Interface Marker, not necessary for AutoQuery or AutoQuery CRUD APIs which is inferred from their base classes.
Otherwise Send* APIs are designed to fallback to use ServiceStack's pre-defined Routes.
I commence in REST and I have some questions:
What type must the controller return? Typically, I'm asking if my Rest #Controller must return Item object as it is or encapsulate it in ResponseEntity in order to specify http-status-code.
What http status code to use in a GET method on a particular item ("/items/2") if the given item does not exists: HttpMediaStatus.OK(200) and null return or HttpStatus.NO_CONTENT(204) and null return ?
Second part: I saw it was possible to specify #Produces and #Consumes on WS method but what the use of that? My application and my methods work so, why specify MediaType.APPLICATION_JSON_VALUE? Doesn't Spring/SpringBoot automatically convert Item or ResponseEntity into json?
Context: using Spring Boot, hibernate, REST webservice.
Thank you.
Many questions in one, I'll provide short answers with a bunch of link to relevant articles and the reference documentation.
What type must the controller return?
Depends on your annotation and the RESTful-ness of your service. There are three annotations you can use for controllers: #Controller, #RestController and #RepositoryRestController.
Controller is the base annotation to mark your class as a controller. The return type of the controller endpoint methods can be many things, I invite you to read this dedicated post to get a grasp of it.
When developing a pure-REST service, you will focus on using RestController and RepositoryRestController.
RestControlleris Controller + ResponseBody. It binds the return value of the endpoint method to the web response body:
#RestController
public ItemController {
#RequestMapping("/items/{id}")
public Item getItem(#PathVariable("id") String id) {
Item item = ...
return item;
}
}
With this, when you hit http:/.../api/items/foo, Spring does its magic, automatically converting the item to a ResponseEntity with a relevant 40X status code and some default HTTP headers.
At some point, you will need more control over the status code and headers, while still benefiting from Spring Data REST's settings. That's when you will use RepositoryRestController with a ResponseEntity<Item> as return type, see the example the Spring Data REST reference.
What http status code to use in a GET method on a particular item if the given item does not exists?
Bluntly said: use HttpStatus.NOT_FOUND. You're looking for a resource that does not exist, there's something wrong.
That being said, it is completely up to you to decide how to handle missing resources in your project. If your workflow justifies it, a missing resource could be something completely acceptable that indeed returns a 20X response, though you may expect users of your API to get confused if you haven't warned them or provided some documentation (we are creatures of habits and conventions). But I'd still start with a 404 status code.
(...) #Produces and #Consumes on WS method but what the use of that? My application and my methods work so, why specify MediaType.APPLICATION_JSON_VALUE? Doesn't Spring/SpringBoot automatically convert Item or ResponseEntity into json?
#Consumes and #Produces are respectively matched against content-type and accept headers from the request. It's a mean of restricting the input accepted and the output provided by your endpoint method.
Since we're talking about a REST service, communications between clients of the API and the service are expected to be JSON-formatted. Thanks to Spring HATEOAS, the answer are actually formatted with the application/hal+json content-type.
In that scenario, you can indeed not bother with those two annotations. You will need them if you develop a service that accepts different content-types (application/text, application/json, application/xml...) and provides, for instance, HTML views to users of your website and JSON or XML response to automated clients of your service.
For real life examples:
Facebook provides the Graph API for applications to read to/write from its graph, while users happily (?) surf on web pages
Google does the same with the Google Maps API
I have a ServletFilter (which happens to be a GuiceShiroFilter) that processes incoming web requests before they go to a Jersey 1.x Resource.
However, in some situations (namely when Shiro finds that the request is not authenticated), I want to change which Jersey resource answers my request, without the resource that otherwise would have answered even being able to respond.
Here's what I have (in my Shiro AuthenticatingFilter.onLoginFailure()):
ServletRequest request = ...;
RequestDispatcher disp = request.getRequestDispatcher("/resource/that/always/responsds/with/a/403");
try {
disp.forward(request, response);
} catch (ServletException | IOException e) {
e.printStackTrace();
}
// this is needed to prevent the woud-be resource from responding as well
return false;
The problem of this server-side redirect is that not returning false will invoke both my resource for "/resource/that/always/responsds/with/a/403" and the original would-be response, and in the best case the response body contains both responses concatenated.
Is there a way to modify an existing instance of (Http)ServletRequest from a Filter such that later on, only the redirected-to resource can answer?
I dug into the issue a little bit and I realized that there is little I can do here, given that I don't control how the filter chain is processed further.
In a generic Filter, the implementer can wrap the current ServletRequest (in doFilter() in a HttpServletRequestWrapper implementation. This wrapper can then override the request URI. However, this requires that the implementer has control over how the filter chain is continued (which is where the wrapped request can be fed back into the execution path), but this is not the case in my situation, where Shiro controls that.
With Shiro, the filter chain continuation is controlled in AdviceFilter.doFilterInternal(), many layers above my own AuthenticatingFilter implementation.
So for now, my best bet is to do what I already described above: Invoke another resource - free from filters - by using a RequestDispatcher and stop the filter chain by returning false at the end of my AuthenticatingFilter's onLoginFailure()
I have to consume a service provided by one of our partners. I was given little direction, but was told the security was to be PasswordDigest. I looked it up and immediatly saw lots of references to WSE, so off I went. It was very easy to implement and in no time I had a standard WSE user token using PasswordDigest sitting in the SOAP headers of my messages.
When we started testing today I was immediatly told (by the error message) that things weren't right. Turns out, out partner doesn't look in the SOAP header, but rather wants the security info in the http header.
I have seen lots of articles on how to add custom http headers to a proxy class, but my proxy inherits from SoapHttpClientProtocol which doesn't have a headers collection to add to. I was looking at making a raw httpWebRequest, but I have a specific method to access that has some complex parameters to deal with (and besides it feels like going backwords).
What is the best way to add custom http headers to a service proxy class that doesn't have a GetWebRequest method?
For reference:
Proxy class decleration:
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Web.Services", "2.0.50727.3053")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Web.Services.WebServiceBindingAttribute(Name="MtomServiceSoap11", namespace="http://ws.xxxxxxx.com/")]
public partial class MtomServiceService : System.Web.Services.Protocols.SoapHttpClientProtocol {
Target method I need to call:
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Bare)]
[return: System.Xml.Serialization.XmlElementAttribute("uploadDocumentResponse", Namespace="http://ws.edsmtom.citizensfla.com/")]
public uploadDocumentResponse uploadDocument([System.Xml.Serialization.XmlElementAttribute(Namespace="http://ws.xxxxxxx.com/")] uploadDocumentRequest uploadDocumentRequest) {
object[] results = this.Invoke("uploadDocument", new object[] {
uploadDocumentRequest});
return ((uploadDocumentResponse)(results[0]));
}
}
The actual call to the Service is simple. The objects being pass in are not:
request.criteria = docCriteria;
request.document = document;
var result = service.uploadDocument(request);
Thanks.
It figures that 30 minutes after posting I would stumble across the answer. While the proxy class decelaration does not create a GetWebRequest method, its base class System.Web.Services.Protocols.SoapHttpClientProtocol has it and it can be overridden.
protected override System.Net.WebRequest GetWebRequest(Uri uri)
{
var request = base.GetWebRequest(uri);
request.Headers.Add("blah", "blah"); // <----
return request;
}
I am currently using Jersey Framework (JAX-RS implementation) for building RESTful Web Services. The Resource classes in the project have implemented the standard HTTP operations - GET,POST & DELETE. I am trying to figure out how to send request parameters from client to these methods.
For GET it would be in the query string(extract using #QueryParam) and POST would be name/value pair list (extract using #FormParam) sent in with the request body. I tested them using HTTPClient and worked fine. For DELETE operation, I am not finding any conclusive answers on the parameter type/format. Does DELETE operation receive parameters in the query string(extract using #QueryParam) or in the body(extract using #FormParam)?
In most DELETE examples on the web, I observe the use of #PathParam annotation for parameter extraction(this would be from the query string again).
Is this the correct way of passing parameters to the DELETE method? I just want to be careful here so that I am not violating any REST principles.
Yes, its up to you, but as I get REST ideology, DELETE URL should delete something that is returned by a GET URL request. For example, if
GET http://server/app/item/45678
returns item with id 45678,
DELETE http://server/app/item/45678
should delete it.
Thus, I think it is better to use PathParam than QueryParam, when QueryParam can be used to control some aspects of work.
DELETE http://server/app/item/45678?wipeData=true
The DELETE method should use the URL to identify the resource to delete. This means you can use either path parameters or query parameters.
Beyond that, there is no right and wrong way to construct an URL as far as REST is concerned.
You can use like this
URL is http://yourapp/person/personid
#DELETE
#Path("/person/{id}")
#Produces(MediaType.APPLICATION_JSON)
public Response deletePerson(#PathParam("id") String id){
Result result = new Result();
try{
persenService.deletePerson(id);
result.setResponce("success");
}
catch (Exception e){
result.setResponce("fail");
e.printStackTrace();
}
return Response.status(200).entity(result).build();
}
#QueryParam would be the correct way. #PathParam is only for things before any url parameters (stuff after the '?'). And #FormParam is only for submitted web forms that have the form content type.