I have a client set up to send a request to the National Weather Service SOAP server. I am receiving the response that I expect, but I am unsure as to the best way to extract the data from it that I need.
For example, there is a lot of extra data in the XML (in the SOAPBody), but I only want to grab the data for the parameters that I set (such as temperature) to my POJO.
What's the best way to extract this data?
I started out trying to consume SOAP Web Services by hand like you describe - there are better ways.
There are libraries out there that will do all the work for you - no need to parse anything by hand.
Check out JAX-WS. Most Modern IDEs (Certainly Netbeans and Eclipse) also provide point and click support for building web service clients given a WSDL.
The biggest potential problem down this route is if there's no WSDL, or the WSDL is wrong, in which case the tooling I've linked might struggle.
The next safest thing would be to use an XML Parser like JAXP's SAX & DOM etc (they're right there in your JRE) to parse the response and then walk the data structures involved.
Finally you could go the string hacking route using splits or regexes but down that path lies a great deal of potential pain - there's more to the XML spec then nested tags.
It's strongly receommended that you not try and decode SOAP by hand :)
Just to expand on what #Brabster said,
Netbeans has extensive Web Service support, especially using the JAX-WS library.
http://www.netbeans.org/kb/60/websvc/jax-ws.html#Exercise_3_1
Related
I am learning about REST apis and after some time of researching, I know the basics of how REST works and I can write an api that generates a JSON response in the web browser with appropriate url. However, I can't seem to understand what is the purpose of it. Surely just generating JSON response seems useless for production application, as you have to assume that most of your website visitors won't even know what JSON is, so there must be some other uses of rest api that I still don't know about. I have been searching a lot about why I should use a rest api, but besides websites praising it ("because it is scalable, portable, flexible" and so on and on) and saying that JSON is simpe yet powerful data exchange format, I have found no concrete answer.
As of this particular case, I am learning to develop RESTful api with Spring. I understand simple CRUD actions using #RestController, but It seems ridiculous to just sent JSON object as a response and especially to expect a client to understand JSON data.
So I am guessing that there must be some other uses for RESTful api that I am not aware of and can't seem to look up either.
So my questions are:
Why should I write RESTful controller if all it does is generate JSON data as a response.
1.1) I am assuming that it IS NOT all it does, so why is it necessary exactly?
Where and what should I use JSON data for?
I know that I am far from understanding this fully, so there probably are many misconceptions, but I want to understand the reasoning behind everything I do and not blindly follow whatever studying resources say, so I am asking it here. Thank you for your time
Its very important to understand that API (yeah, capital letters are quite important) is acronym for Application Programming Interface, it is not user interface, it is interface for other programs/applications to use.
So, API will be used solely by some other code to exchange data (interface with each other) and to do this you need some structure or protocol to follow by both sides of this exchange, otherwise applications will not understand each other.
So, you decided that your application (service) will provide some API for other applications (again, not users), you decided what kind of functions those applications will be able to consume (like get current weather, or create new user - basically methods in your controller).
Next step is to define protocol - how exactly information will be presented on wire (serialized to binary stream, because you can send only bytes via physical connection), JSON is quite popular choice because it provides quite easy format to parse for application (libraries for JSON exist for almost any programming language), but also is still readable enough for humans (there many offline and online formatters to help you).
But, JSON is not most efficient in terms of space, this is why you can pick many others - BSON, protobuff, kryo, java RMI and so on.
Now, lets actually answer you questions:
Why should I write RESTful controller if all it does is generate JSON data as a response.
Because you as developer decided to provide API for others, and you decided to use JSON as data format, and you decided so (probably) because it is quite famous and easy to work with, it is provided by default in many frameworks, etc, but there is no real objective reasons for that, several years ago SOAP/XML was holding the same niche, for the very same reasons.
Where and what should I use JSON data for?
Anywhere and for everything where you think it will fit: non performance critical inter-service communications, config files, personal notes, structured or non structured data, JSON is very flexible format (as almost any other generic purpose one, like XML or simple text files).
A ReST API will usually be called by another service or e.g. by a JavaScript based frontend application, not directly by users. JSON can be processed quite comfortably by other applications, that's why it's widely used (by now there are other formats as well, especially for high performance applications, but that's on an advanced level).
So to your questions specifically: If you are offering a service, that will be used by other applications, then use a ReST API with JSON responses, if you are offering an application that will be used by users directly, and don't want to have a JavaScript frontend application, you would use something like Thymeleaf to implement the frontend and have that returned in your controllers.
Have a web service that implements REST (sort of) ,
Client request is made for some entity
Server populates a model (that was created with JAXB)
Converted to Xml and sent back
Client reads Xml into same JAXB Model
This works fine, but i dont use any REST libraries.
Am I missing out, I cant see what complexity they could hide because the code to send /receive a request and convert to/from JAXB is already pretty simple.
For your basic use case, you will probably not benefit a lot from using JAX-RS(http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services), which is the Java standard for REST.
However, as you can see if you follow the link, there are some useful annotations, which might make your life easier later on. For example, if you would start returning plain text next to xml as well, based on request header, that becomes incredibly easy to configure(with #Produces).
Same for when you want to support multiple types of request payloads(#Consumes).
Check http://docs.oracle.com/javaee/6/tutorial/doc/gkknj.html for a good tutorial.
In short, JAX-RS offers a lot of useful functionality with regard to request headers, parameters,etc.. that would otherwise be harder to implement.
However, many applications do not need this "full fine-grained REST" support, so sticking with just JAXB might be enough for your needs.
I'm currently working on a project which needs some server-client communication. We're planning to use Websockets and a Java server (Jetty) on the server side. So, messages sent must be interpreted with Java from the server and with JavaScript from the client.
Now we're thinking about a protocol and which structure the messages should have. We already have a reference implementation which uses XML messages. But since JSON is designed to be used with JavaScript we're also thinking about the possibility to use JSON-Strings.
Messages will contain data which consists of XML strings and some meta information which is needed to process this data (i.e. store it in a database, redirect is to other clients...). It would be important if the processing of the messages (parsing and creating) would be easy and fast on both server and client side since the application should feature real time speed.
Since we have not the time to test both of the technologies I would be happy about some suggestions based on personal experience or on technical aspects. Is one of the technics more usable than the other or are there any drawbacks in one of them?
Thanks in advance.
JSON is infinitely easier to work with, in my opinion. It is far easier to access something like data.foo.bar.name than trying to work your way to the corresponding node in XML.
XML is okay for data files, albeit still iffy, but for client-server communication I highly recommend JSON.
You are opening a can of worms (again, not the first time).
have a look at this JSON vs XML. also a quick serach on stackoverflow will also be good.
this question might be duplicated across. Like this Stackoverflow XML vs JSON.
In the end answers stays the same. It depends on you. I though agree with many comments there that sometime, XML is overkill (and sometime not).
I agree with Kolink,
The reason, it is better to use JSON because the XML has a big Header, which means each transfer has a big overhead.
For iOS or Android, you have to use JSON as opposed to WLAN XML.
I agree with Kolink, but if you already have an XML scheme in place, I'd use XML to save you some headaches on the Java-side. It really depends on who's doing the most work.
Also, JSON is more compact, so you could save bandwidth using its format.
There seem to be some libraries for parsing JSON in Java, so it may not be too hard to switch formats.
http://json.org/java/
Pals,
I have a requirement to establish a communication channel between C++ and Java layer of my application for the exchange of objects and their properties.
I have got the following options:
XML / SOAP
Postgre SQL
Can you please advice me the Pros & Cons on these. Please share your experiences on the implementation complexities.
Thanks,
Gtk
If the option is between those I would choose XML
Object <=> XML
Java side Simple, C++ side XML Objects
Reason, its simpler for what you want, i.e. pass language objects and not Data Base
Ah, could you specify the communication channel between the apps ?
UPDATE
If you can use JSON I would recommend it instead of XML, here is why.
Another option would be JMS. There are C++ clients out there.
Every time I see XML I think RESTful web service. Both platforms you mentioned have some form of tooling to marshal & unmarshal XML. There are plenty of working examples out in the wild, so a Google/Bing search is good. A nice side-effect is once you have those interfaces built, anything can connect to them.
If you really want to bother with generating a WSDL, then feel free to go the SOAP route. However, speaking with several years of web service integration experience, RESTful is so gosh darned simple compared to anything else.
I would like to suggest a third option : YAML
You have parsing library in YAML for both java and C++. In my experience, it's easier to debug exchange in YAML that in XML (especially if you got full text field or cyclic data structure).
I depends of the kind of message you transfer.
If your message are individual entity that have a short live, I would go for XML, YAML or something similar.
If your message contains information that is going to be used later on and refer to information in previous messages, I would use a database.
This is more of a design question I suppose. My company offers a web service to our client that spits data out in a custom xml format. I'd like to build a java library we can offer so our customers can just feed it the url and we will turn it into a set of POJOs built from the response.
I can obviously just create a library that will do some simple xml parsing and building of the POJOs but I'm looking to build something a bit more robust.
My brain is pulling me in a million directions, wondering if anyone has some pointers or some code to poke at. Was thinking about adding an Abdera extension, but it's not really a syndication format that fits the Abdera model. And most of the popular service libraries (twitter, facebook) all rely on standards format parsers, of which our format isn't.
Are you familiar with JAXB?
here is the tutorial: https://jaxb.dev.java.net/tutorial/