We Keep Coding

How to use HEAD to check if file exests

I want to use this Spring Endpoint to upload a file.
#PostMapping(value = "/upload", produces = { MediaType.APPLICATION_JSON_VALUE })
public ResponseEntity<StringResponseDTO> uploadFile(#RequestParam("file") MultipartFile file,
RedirectAttributes redirectAttributes, #RequestParam("id") Integer merchantId) throws Exception {
..............
return ResponseEntity.ok(new StringResponseDTO("test"));
}
Angular code:
imports(file: any, id: number) {
const formData = new FormData();
formData.append('file', file, file.name);
return this.http.post(environment.api.urls.merchants.uploadLogo, formData, {
params: { id: id.toString() }
}).pipe(
catchError(this.handleError)
);
}
In my case I want to display a download link into Angular if the file is present. How I can make a request using the HEAD and check if the file is present?
I don;t want to download the file in order to verify the the file if available for download.

HTTP Request Methods
Before addressing your question[s] directly I want to address the concept of an HTTP Request Method's in general. An HTTP Request Method is used to indicate the desired action to be performed on the identified resource. The following methods are standardized to some extent
GET
POST
HEAD
OPTIONS
PUT
DELETE
PATCH
CONNECT
What the resource represents and how you actual implement the service and invocation of the service ( the request ) is completely up to you.
With that being said, it would be accurate to say that a GET request that is used explicitly to update an existing value is implemented incorrectly.
Additionally, what method you choose will be limit your functionality if you are using any type of client-side or server-side platform or library. For example, Angular won't provide a means of sending a request body with a GET, even though you technically could craft an HTTP GET call that contains a request body.
Spring Boot
Looking at your code you explicitly set your service as a POST service with the following code
#PostMapping(value = "/upload", produces = { MediaType.APPLICATION_JSON_VALUE })
You can explicitly specify your service as a HEAD service by swapping that line with the following
#RequestMapping( value = "/upload", method = RequestMethod.HEAD, produces = { MediaType.APPLICATION_JSON_VALUE } )
However, remember that a HEAD method should basically be a GET method but should only return headers. In the sample provided I cannot tell what your DTO does specifically, but it appears to be returning a body. Instead you can return only headers using something like
String fileId = ....
HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.set("fileId", fileId);
return ResponseEntity.ok().headers(responseHeaders);
The naming convention you are using is not RESTful. Firstly, /upload endpoint is not resource oriented because there is no resource specified in your path.
Additionally uploading is probably not the correct verb to use, since what you're actually doing is checking or validating. I would probably swap the endpoint for something like
#RequestMapping( value = "/resourceName/validate", method = RequestMethod.HEAD, produces = { MediaType.APPLICATION_JSON_VALUE } )
Replacing resourceName with the name of your resource.
Angular
Likewise in your Angular call your invocation is explicitly POST
return this.http.post( ... )
Similarly Angular has an $http.head method
return this.http.head( ... )
Unlike Spring Boot, you may not be able to simply swap out line for line though. You will need to make sure that the parameters in head match the parameters in post, and if not you will need to adjust accordingly.
Summary
My answer can be summarized as follows
You may want to rethink your use of HEAD in general ( does it apply here? )
You may want to rename your endpoint to be resource-oriented
If you do want to use head you need to change your Spring Boot annotation
If you do want to use head you need to change your Spring Boot response to only include headers
If you do want to use had you need to change your Angular request to use the head method

RestTemplate Test w specific parameters for REST Controller

I am writing Integration Tests for controllers using RestTemplate, so far I have been able to call most , however haven't been able to tackle this particular parameter combination.
I know how to deal with headers, GET or PUT parameters, but multiple String is sole one that have yet to figure. Dunno if #Annotations make difference.
#RequestMapping(value="/getBook", method = GET)
#ResponseStatus(OK)
public #ResponseBody
GetBookResponse getBook(#RequestParam("isbnID") String isbnID, #RequestParam(required=false) Double price, #RequestHeader(required=false) String publisher)
{
.....
}
and how this would work in the case for POST
Normally I use ResponseEntity to get response but been stuck pn how to prep it.

Typically we create a new HttpRequest and add the request parameters to it and submit your HttpRequest with all its corresponding parameters in your post. I don't know how to implement it with the framework you are using though. I've written tests for controllers and this is how I did it. GET request usually has just one parameter in the url so you don't really have to add request parameters but POST should have request parameters set to the httpRequest.

Any simple way to test a #RequestBody method?

If I have a #Controller method whose parameter is a #RequestBody param, I usually have to write some jQuery script or something similar to perform an AJAX request with JSON object in order to call that method. If I tried calling that method via a web browser directly, it returns with a Error 415 Unsupported Media Type.
Is there any alternative to just quickly call such method using browser without having to write some jQuery code? Like perhaps a way to write the JSON object in the URL/address bar?
code:
#RequestMapping("testCall")
#ResponseBody
public List<TestObject> getTestCall (#RequestBody TestParams testParams) {
return stuff;
}
public class TestParams {
private Integer testNumber;
//getter/setter for testNumber
}
I thought maybe I could just do:
http://localhost/testCall?testNumber=1
maybe Spring would auto populate a new TestParams instance with that property set to 1 but that didnt work...
maybe I need to do something extra for that?

The whole point of a #RequestBody annotated parameters is for the Spring MVC stack to use the HTTP request body to produce an argument that will be bound to the parameter. As such, you need to provide a request body. Sending a request body is very atypical for a GET request. As such, browsers don't typically support it, at least not when simply entering an address in the address bar and submitting the request.
You'll need to use a different HTTP client, like jQuery. I typically have a small Java project in Eclipse that's setup with an Apache HTTP components client which can send HTTP requests to whatever server. It takes a few seconds/minutes to setup the correct request body and run.

I have spent the last year building a REST API, and by far the best way to exercise that API manually is using the Chrome Extension, Postman. I cannot recommend this tool enough.
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
To test your simple example you'll need to invoke a POST (I assume that as you have a request body, but your controller method doesn't define a HTTP Verb) using POSTMAN to your Url (like the following example):
POST /contextRoot/testCall
{
"testNumber": 1
}
If you want to test your API automatically (which I recommend), you can use the excellent Spring Mvc Test project. This allows your to call your API via a rest-like DSL and assert that the response is in the shape you want. More details can be found here:
http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/testing.html#spring-mvc-test-framework

you can add request params to the getTestCall method:
#RequestParam(value = "testNumber", required = false, defaultValue = "") String testNumber

There is a chrome app called Advanced REST client. You can pass the data in form of json to your controller using this chrome app. For eg. json data is
id:1,
name:"xyz"
whereas the controller can have #RequestBody Person form.
The Person class would be a POJO having id and name as instance variables. The Spring would automatically map the json data to the form.
I think this is the easiest and simplest way of checking your spring controller.
Check the extension Advanced REST client here

From what I know You can send JSON object to the webbrowser and it will be displayed without further need of AJAX.
useful tutorial:
http://www.mkyong.com/spring-mvc/spring-3-mvc-and-json-example/

Jersey web service proxy

I am trying to implement a web service that proxies another service that I want to hide from external users of the API. Basically I want to play the middle man to have ability to add functionality to the hidden api which is solr.
I have to following code:
#POST
#Path("/update/{collection}")
public Response update(#PathParam("collection") String collection,
#Context Request request) {
//extract URL params
//update URL to target internal web service
//put body from incoming request to outgoing request
//send request and relay response back to original requestor
}
I know that I need to rewrite the URL to point to the internally available service adding the parameters coming from either the URL or the body.
This is where I am confused how can I access the original request body and pass it to the internal web service without having to unmarshall the content? Request object does not seem to give me the methods to performs those actions.
I am looking for Objects I should be using with potential methods that would help me. I would also like to get some documentation if someone knows any I have not really found anything targeting similar or portable behaviour.

Per section 4.2.4 of the JSR-311 spec, all JAX-RS implementations must provide access to the request body as byte[], String, or InputStream.
You can use UriInfo to get information on the query parameters. It would look something like this:
#POST
#Path("/update/{collection}")
public Response update(#PathParam("collection") String collection, #Context UriInfo info, InputStream inputStream)
{
String fullPath = info.getAbsolutePath().toASCIIString();
System.out.println("full request path: " + fullPath);
// query params are also available from a map. query params can be repeated,
// so the Map values are actually Lists. getFirst is a convenience method
// to get the value of the first occurrence of a given query param
String foo = info.getQueryParameters().getFirst("bar");
// do the rewrite...
String newURL = SomeOtherClass.rewrite(fullPath);
// the InputStream will have the body of the request. use your favorite
// HTTP client to make the request to Solr.
String solrResponse = SomeHttpLibrary.post(newURL, inputStream);
// send the response back to the client
return Response.ok(solrResponse).build();
One other thought. It looks like you're simply rewriting the requests and passing through to Solr. There are a few others ways that you could do this.
If you happen to have a web server in front of your Java app server or Servlet container, you could potentially accomplish your task without writing any Java code. Unless the rewrite conditions were extremely complex, my personal preference would be to try doing this with Apache mod_proxy and mod_rewrite.
There are also libraries for Java available that will rewrite URLs after they hit the app server but before they reach your code. For instance, https://code.google.com/p/urlrewritefilter/. With something like that, you'd only need to write a very simple method that invoked Solr because the URL would be rewritten before it hits your REST resource. For the record, I haven't actually tried using that particular library with Jersey.

1/ for the question of the gateway taht will hide the database or index, I would rather use and endpoint that is configured with #Path({regex}) (instead of rebuilding a regexp analyser in your endpoint) .
Use this regex directly in the #path, this is a good practice.
Please take a look at another post that is close to this : #Path and regular expression (Jersey/REST)
for exemple you can have regexp like this one :
#Path("/user/{name : [a-zA-Z][a-zA-Z_0-9]}")
2/ Second point in order to process all the request from one endpoint, you will need to have a dynamic parameter. I would use a MultivaluedMap that gives you the possibility to add params to the request without modifying your endpoint :
#POST
#Path("/search")
#Consumes(MediaType.APPLICATION_FORM_URLENCODED)
#Produces({"application/json"})
public Response search( MultivaluedMap<String, String> params ) {
// perform search operations
return search( params);
}
3/ My 3rd advice is Reuse : make economy and economy make fewer bugs.
it's such a pitty to rewrite a rest api in order to perform solr search. You can hide the params and the endpoint, but could be great to keep the solr uri Rest formatting of the params in order to reuse all the search logic of solr directly in your api. This will make you perform a great economy in code even if you hide your solr instance behind you REST GATEWAY SERVER.
in this case you can imagine :
1. receive a query in search gateway endpoint
2. Transform the query to add your params, controls...
3. execute the REST query on solr (behind your gateway).

Why is my Spring service returning any content type requested by client?

I have a Spring rest service using Spring 3.1.0.RELEASE. Here is the relevant code for the service call in question:
#RequestMapping(value="/{var1}", method=RequestMethod.GET, produces="application/json")
#ResponseBody
public String getSomeStuff(#PathVariable final String var1) {
return myJsonString;
}
If I call this using the following curl command, it happily returns me my json string with a content-type of application/xml whereas I would expect a 406 based on the Spring 3.1 docs:
curl -v -H "Accept: application/xml" http://localhost:8080/MyServiceSite/myvalue
There is no extra configuration in my app for this service (no serialization), I am returning raw json with no post-processing for the service configured. I'm certain I have missed something, can anyone point out anything I may have missed?
Edit: Here is the documentation I was looking at when attempting to get this working. Specifically section 16.3.2.5. My code is very similar except that their code looks like it assumes config setup to let Spring handle serialization. Perhaps the produces does not work when bypassing the Spring serialization?
Edit: I changed my expectation for the response code. A 415 would indicate I was sending improper content in my request body whereas 406 is proper for having an accept header that doesn't jive with the content type of the server.
Anyway, I have changed this method do return a Map and added config for it to serialize to json and now if I send an invalid content type from the client I get the proper 406 response. It seems that maybe the "produces" setting is ignored when the output of the method is not being serialized.

The produces condition is new to Spring MVC 3.1 and is only supported with the RequestMappingHandlerMapping and related #MVC support classes, also new in Spring 3.1. My guess is that you're using the 3.0 #MVC support classes, which do not support the produces condition. Your code otherwise is correct and so are your expectations of what should happen.
The use of headers="Accept=application/json" is unnecessary in 3.1. That's exactly what the produces condition was introduced for.

What about the headers attribute for the #RequestMapping. You could set the Accept header in there. Something like:
#RequestMapping(value="/{var1}", method=RequestMethod.GET, produces="application/json", headers = "Accept=application/json")
#ResponseBody
public String getSomeStuff(#PathVariable final String var1) {
return myJsonString;
}
I don't know how Spring would handle a request to that path without a matching header. If it doesn't give what you want you might need to define a similar mapping without the headers and have it send back a ResponseEntity and set the response code or something, but I would hope it would handle it appropriately.