for a REST PUT service, im trying to use xml as the payload. My question is can I have the whole payload as xml? or should I do something like Data=<mydata>......</mydada>?
basically
<mydata>......</mydada>
or
Data=<mydata>......</mydada>
Sure you can just set the mediaType to be application/xml just as you can for json or plain text. The first example is valid XML, second one is not. So the first one can be done.
I am not sure what framework you are using. For example if you plan to use Spring you can take a look at an example here.
The basic idea is that you define the media type to be application/xml . You can also specicfy a marshaller/unmarshaller (ie. using JAXB) if you want to marshal/unmarshal from a Java bean.
Related
I am creating a web application in Java and I want to completely divide the frontend from the server part. Therefore everything is going to be implemented via services, particularly JSON Rest services. I want to have a common message format, something like this (for convenience I write it as XML, but am going to use JSON - should be a matter of configuration anyway):
<response>
<time>...</time>
<status>
<code></code>
<message></message>
</status>
<data>
...my entities resulting from the operations...
</data>
</response>
My question is how to implement and use this custom format in my methods universally? That means, that in case of everything ran fine, I just want to write something like response.setData(data) and return the object. Otherwise the error handler would take care. Thanks for help.
Take a look at the JAX-RS spec or Jersey User Guide especially section devoted to JSON (JAXB based JSON support).
The simplest way of doing this is to use JAXB to create the tooled version of the structure (with something like Jackson as the serialization engine) and then to create a factory method somewhere that will make the structure for you without you having to specify anything extra yourself.
I'm not sure about the exact denomination, but I have an "web asp service" (from a .NET application) who gives me a XML file. (There is no WSDL...)
For exemple, I can question the web service with an URL like that :
http://Connectiquetest:86/Vaudoise/srv_db/db2_personnes.asp?Nopers=529720&SearchMode=1&Name=Smith
Where Nopers=52920, SearchMode=1 and Name=Smith are used to return to me the response I want. (The URL is for an internal system, you cannot access to it without a VPN)
The content type return is : "text/xml" (it's a classic well-formed XML).
So, how can I use this informations to make a call from a Java application to receive the XML ? Anybody can tell me what is it exactly (maybe a specific implementation of SOAP ?)
Thanks !
The most simple (and yet most labor intensive) approach would be to open an HttpURLConnection. You can do that by calling URL.openConnection(). The URL object would obviously be based on the URL you mentioned, optionally appending the parameters Nopers, SearchMode and Name. You could then call getInputStream() to access the response of the call. Next would be parsing the XML to interpret the result.
However, as said, this requires a lot of low-level code (especially when reading the input, parsing the XML, and so on). Consider using something like Apache HttpComponents for HTTP-related work, combined with something like JAXB for easily converting the retrieved XML to plain old Java objects.
Using JAXB might require you to have an XML schema. In the ideal situation, it already exists (written by the people who wrote the ASP service). In the sub-ideal situation, you'll have to derive it yourself.
Requirement
I am building a REST API. It has two REST calls. The call /format to output formatted JSON based on the parameters provided. The call /raw with same parameters should output JSON with raw values (without the formatting). The formatting here would be locale specific like date changes, displaying the correct currency, decimal formatting, time formatting etc for the values.
Tools
Java, Tomcat, Spring, Apache CXF, JAX-RS and Jackson.
Implementation
REST service is setup and works fine. No problems there. I have written seperate custom serializers in which I provide desired formatting using NumberFormat, DateFormat, DecimalFormat etc. I have extended the SimpleModule from Jackson to register all my custom serializers mentioned above. I am using two separate ObjectMapper (FomatOM and RawOM).FormatOM registers the custom Module for formatted JSON output, RawOM is for raw JSON output as per the requirement. These two objectmappers are registered to two different JacksonJsonProviders and declared as beans in my spring config xml. For /format I use FormatOM with custom serializers, and in /raw I use RawOM.
Problem
It doesn't work as I would have expected. I expected that when I make a request through /format call the FormatOM would be used and for /raw RawOM would be used. What is happening is whichever call I make first, subsequent calls are served using the same ObjectMapper. Thus, if the first call is /raw; subsequent calls to /format or /raw render raw JSON output. After a Tomcat restart, if the first call is to /format then subsequent calls to either API calls render formatted JSON output
Questions
1. How do you achieve my requirement for rendering formatted + raw JSON
output?
2. What's is wrong with my implementation?
3. Any ideas or suggestions or critiques?
4. Any other way to have request based mappers?
Thanks
One work-around is just to use a StreamingOutput, and bundle specific ObjectMapper in there, use it directly (ObjectMapper.writeValue(output, value);)
Thanks for your answer StaxMan. Since I am using Spring, I decided to inject the JacksonJsonProvider and do JacksonJsonProvider.setMapper(mapper) to set the mapper per request. If anyone has tried the above approach and ran into a problem do let me know. If I run into any sort of issue, I shall update this answer.
I found a couple of questions somewhat related to this:
httpclient-request-set-attribute-question
commons-httpclient-adding-query-string-parameters-to-get-post-request
but I think I am trying to do something different here:
I have a servlet which will set an attribute into the request. In my Java client, I am using HTTP Components library, and I want to read the attribute in my client.
Is this an invalid use case for the HTTP Components library?
If not, one way would be to serialize the object in the servlet and de-serialize it back in the client, but I am not sure if that is the best practice.
Is there an API I am missing here?
Request attributes are not accessible to the client.
You should send them as response somehow (write them as key-value pairs, serialize the object graph with JSON, etc.). So yes, that's the accepted practice
This must have been answered previously, but my Google powers are off today and I have been struggling with this for a bit. We are migrating from an old PHP base to a Jersey-based JVM stack, which will ultimately provide a JSON-based RESTful API that can be consumed from many applications. Things have been really good so far and we love the easy POJO-to-JSON conversion. However, we are dealing with difficulties in Cross-Domain JSON requests. We essentially have all of our responses returning JSON (using #Produces("application/json") and the com.sun.jersey.api.json.POJOMappingFeature set to true) but for JSONP support we need to change our methods to return an instance of JSONWithPadding. This of course also requires us to add a #QueryParam("callback") parameter to each method, which will essentially duplicate our efforts, causing two methods to be needed to respond with the same data depending on whether or not there is a callback parameter in the request. Obviously, this is not what we want.
So we essentially have tried a couple different options. Being relatively new to Jersey, I am sure this problem has been solved. I read from a few places that I could write a request filter or I could extend the JSON Provider. My ideal solution is to have no impact on our data or logic layers and instead have some code that says "if there is a call back parameter, surround the JSON with the callback, otherwise just return the JSON". A solution was found here:
http://jersey.576304.n2.nabble.com/JsonP-without-using-JSONWithPadding-td7015082.html
However, that solution extends the Jackson JSON object, not the default JSON provider.
What are the best practices? If I am on the right track, what is class for the default JSON filter that I can extend? Is there any additional configuration needed? Am I completely off track?
If all your resource methods return JSONWithPadding object, then Jersey automatically figures out if it should return JSON (i.e. just the object wrapped by it) or the callback as well based on the requested media type - i.e. if the media type requested by the client is any of application/javascript, application/x-javascript, text/ecmascript, application/ecmascript or text/jscript, then Jersey returns the object wrapped by the callback. If the requested media type is application/json, Jersey returns the JSON object (i.e. does not wrap it with the callback). So, one way to make this work is to make your resource method produce all the above media types (including application/json), always return JSONWithPadding and let Jersey figure out what to do.
If this does not work for you, let us know why it does not cover your use case (at users at jersey.java.net). Anyway, in that case you can use ContainerRequest/ResponseFilters. In the request filter you can modify the request headers any way you want (e.g. adjust the accept header) to ensure it matches the right resource method. Then in the response filter you can wrap the response entity using the JSONWithPadding depending on whether the callback query param is available and adjust the content type header.
So what I ultimately ended up doing (before Martin's great response came in) was creating a Filter and a ResponseWrapper that intercepted the output. The basis for the code is at http://docs.oracle.com/cd/B31017_01/web.1013/b28959/filters.htm
Essentially, the filter checks to see if the callback parameter exists. If it does, it prepends the callback to the outputted JSON and appends the ) at the end. This works great for us in our testing, although it has not been hardened yet. While I would have loved for Jersey to be able to handle it automatically, I could not get it to work with jQuery correctly (probably something on my side, not a problem with Jersey). We have pre-existing jQuery calls and we are changing the URLs to look at the new Jersey Server and we really didn't want to go into each $.ajax call to change any headers or content types in the calls if we didn't have to.
Aside from the small issue, Jersey has been great to work with!