We Keep Coding

When developing a RESTful web service, why do I need to write the method return value directly to the body of the response as JSON?

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.

How do I use Google Maps API in a Java code to fetch coordinates of specified location?

In a BI project I'm currently working on, we are in need of geo-coordinates for a list of locations. With the address location (such as "New York, US") as input, the output should be the coordinates as a latitude-longitude pair (like {40.71435, -74.00597}). The behaviour is similar to what is seen on this page.
A similar question earlier on SO points to using the Google Maps API in JavaScript to achieve this, but I'm looking for a Java solution -- some function of the form getCoordinates(location), because this is a small requirement in a larger Java program already in existence.
Any pointers on how I may use the Google Maps API (or any other maps API) in Java to achieve this would be of great help!

You can use the Google Geocoding HTTP API (see here).
To connect to it and get the responses you can use a Java URLConnection (tutorial is here) and parse the response using your favourite Json library (I personally use Jackson)

So you'd like a way to perform Google Maps API Geocoding via Java - here's one that might work for you. The response might not be in the exact same format you need but should be pretty workable:
http://code.google.com/p/geocoder-java/
You can see the final format returned in LatLng.java - just trace the code through starting from GeocodeResponse.java and you'll see the final format - the classes are pretty simple.

Handling messages with Java and JavaScript: JSON or XML?

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/

Parse JSON response from Google Maps page

I'm trying to find the best way of parsing the response from a "normal" (i.e. not using the API) Google Maps page in my java code.
Reason: I want to submit a query string requesting a listing (be it hotels, restaurants etc.) and then parse the JSON that comes back. I had looked into using the Google Maps API, but it doesn't seem to cover what I want to do, as this type of URL:
http://maps.google.de/maps/geo?q=address&output=xml&oe=utf8&sensor=false&key=...
is OK but this isn't:
http://maps.google.de/maps/geo?q=address+hotels&output=xml&oe=utf8&sensor=false&key=...
(due to the "+hotels" term). So I think the only option is to use a google maps response e.g.
http://maps.google.de/maps?q=address+hotels
and parse the JSON information that is included at the end. Does anyone have some hints as to how best accomplish this?

You should first make absolutely sure that the API doesn't support what you need. Checking the docs and maybe even reaching a real Googler might pay off. It strikes me as odd that their API wouldn't support something as simple as adding in another term.
If you're forced to do it the "hard way", there are two main steps:
1) Find and learn a JSON parsing library for Java. I can recommend Jackson -- fast, sturdy, and just released a version 1.0.0.
2) Teach your code to understand the spec the Google uses in their response. This is by far the most challenging part. My apologies, but I know nothing about Google's spec in this area. If you can find official docs, that's best. Or find unofficial docs published by someone else who had to do similar work. Otherwise, you may have to "reverse engineer".

Re. the google api docs: it does seem that what you're trying to do goes against the intention of Google to make their product (= a map) available to you, the developer, for your custom enhancement (by adding business outlet information or whatever). There's plenty of stuff on the Google maps API site describing this. But to parse their data (coming out of their database) and to display it independently of their product would seem to be rather different: section 10.12 of the terms explicitly cover this:
...code.google.com/intl/de/apis/maps/terms.html
However, there are apps out there (the "Around Me" iPhone app, for example) that seem to do just that: there might be a special arrangement between Google and Apple in that regard.
EDIT: alternatively you could look at this problem another way and use the Google Base API feed, since this allows you to build query strings specifying resource, distance, location etc. - i.e. it returns the data you require without using the Maps API (which you don't need anyway, given your description).

Java SWIFT Library

I'm looking for a Java library for SWIFT messages. I want to
parse SWIFT messages into an object model
validate SWIFT messages (including SWIFT network validation rules)
build / change SWIFT messages by using an object model
Theoretically, I need to support all SWIFT message types. But at the moment I need MT103+, MT199, MT502, MT509, MT515 and MT535.
So far I've looked at two libraries
AnaSys Message Objects (link text)
Datamation SWIFT Message Suite (link text)
Both libraries allow to accomplish the tasks mentioned above but in both cases I'm not really happy.
AnaSys uses a internal XML representation for all SWIFT messages which you need to know in order to access the fields of a message. And you need to operate on the DOM of the XML representation, there is no way to say "get the contents of field '50K' of the SWIFT message".
And the Datamation library seems to have the nicer API but does not find all errors.
So does anyone know other SWIFT libraries to use?

Have you looked at WIFE? We use that in our application which translates SWIFT messages to an internal XML format and back again. We haven't had any problems with it. Also, it's licensed under the LGPL, so you can hack it up if you need to. Check it out.

SWIFT is releasing a "Standards Developer Kit" which includes an "MT/XML Schema Library".
From the doc:
"The MT/XML Schema Library is a complete set of XML schema definitions for MT messages, and software which shows how to convert messages from an MT format to an MT XML representation and back. This approach allows XML integration between applications while the MT (FIN) format will continue to be transported over the SWIFT network."
Java source code will also be made available, again from the doc:
"Working sample Java source code that converts a message in MT format to an XML instance and from an XML instance to a message in MT format."
See: http://www.swift.com/support/drc/develop/standards.page
This can be a great aid in dealing with FIN messages in XML syntax.

You can combine the open source implementation WIFE with the commercial validation component from http://www.prowidesoftware.com. It validates that the messages you create with the model or XML representation are good through SWIFT network validation rules.

There is a product call Volanté that make a great job. Their solution is certified by SWIFT and the integration is easy ( I sound like I'm working for them ... I'm not). I've been using it since a couple of month .
IBM is also offering a solution (cannot remember to name right now) but then you are committed to the big blue.

If your company is not comfortable with the LGPL license, You might want to check Progress Sonic ESB, or ArtixDS (recently acquired), TIBCO ActiveWhatever or Oracle/BEA Aqualogic. Chances are you are already using something from these companies and you can get decent discount.

Along with jodonnell, we also use WIFE. It works very well. I'm not sure if it does the network validation rules (#2 on your list) though.

paymentcomponents (http://www.paymentcomponents.com/) parser was easy to use and found all errors. Their site definitely needs work but if u look there, u'll find what u r looking for

I can not really help you out with a Java implementation. Microsoft of course, have their own Biztalk adapter for ISO15022 and 20022. And they will actually do the validation fairly well. But as you say you are actually looking for a java solution.
You might find, as I did when I researched this 6 years ago, that mapping FIN messages to XML and then to into objects, a standard library will only get you partly to your goal. You will have to integrate this with your backend application and whatever market practices you face in the particular messages you need to support.
I finally ended up writing a generic FIN parser /150022 class library in c++.
Anyway, good luck. An idea is to be more specific in your question. What types of messages do you need to support?

Datamation's libraries have evolved since then. If you need a corresponding solution in 2021, you can check FINaplo by PaymentComponents (formerly called Datamation), a multi-purpose implementation for financial messages.
It provides online validation/parse/translation/envelope services, Java SDKs, as well as REST solutions, all including error specifications. I am actually one of the authors.
A demo for a SWIFT MT Java library can be found in this GitHub link.