On 03/03/2013 10:45 PM, Arne Vajh?j wrote:
On 3/1/2013 9:34 PM, Arved Sandstrom wrote:
I just had an epiphany today at work. For years upon years I have used
Java libraries which have grown increasingly cumbersome and finicky and
unreliable to do XML or JSON in a REST context...99 percent of which is
actually super-simple.
The epiphany came when neither Jettison (the default Jersey JSON
library) nor Jackson (which is undoubtedly more modern) could, out of
the box without arcane configuration tweaks, convert a single-item list
into a JSON array. They both just converted the item into a JSON object
and forgot about the array.
Apparently this catches out a lot of people, judging by googling. The
Jackson solutions are many. The point being - leading to my epiphany -
why the hell is this even a problem?
I have probably wasted tens of weeks on the arcana of Jersey, Jackson,
XStream to some extent, JAXB...I'm ditching most all of it. It is an
obstacle.
XStream I actually like for producing and consuming XML. It works
nicely. I'll keep it in the toolbox. But for almost everything I do with
Java REST, there is no call for Jersey (nor Jackson et al. for JSON
(de-)serialization). It's a bunch of extra JARs for no added value.
It occurred to me that for over 90 percent of my POJOs I can write
reliable toJSON() methods that *will not break* and are fully under my
control in a matter of minutes. For anything more I might give
simple-json a whirl - it actually has appealing simplicity.
And Jersey has got to go. Why do we even drink that Kool-Aid? Once
you've got your JSON string a handful of lines of code with an HTTP
client will take care of your REST call. A lot more reliable.
I think we need to split the stuff in 3 parts:
A) server side framework to enable declarative JAX-RS to work in a
servlet container
B) the JSON/POX serializer
C) client side framework
re A)
I don't hear you argue against that. And I don't recall much
criticism from other either.
>
re B)
You don't like the common libraries. I know several people that
don't like them either (I don't have so much personal experience).
But is it really the concept that is wrong or is it just the
implementations?
My guess is still the implementations. I am not too keen on
toJSON, toXML, toJSONAlternative, toXMLALternative etc.etc.
on all DTO's.
We may not always like SOAP and all the associated standards,
but sometimes the "there is only one right way" philosophy
do make life easier.
re C)
I think it is rather common to use plain HttpClient.
Non-Java client to Java service is probably also a very
common combination.
For all of A, B, C, I have no problem with JSON as a data notation. I
have no major problems with SOAP as a protocol, or with the principles
of true RESTful web services [1].
For all of A, B, C, it is specifically implementations that I have a
problem with. Whether language-specific APIs or libraries. JSON is
simple. SOAP *messages* are usually quite simple (WSDL and schemas might
not be, but you infrequently occupy your time with those). JSON as a
payload over HTTP as part of a REST method is simple. SOAP XML via HTTP,
JMS, SMTP is usually quite simple.
*When we look at what is going back and forth*, that's what is simple.
What can be, and often is, elaborately over-engineered, clumsy, buggy,
and not simple are the client and server APIs and libraries.
As to toJSON() or fromXml() type methods, I'm not overly keen on them
either, for maintainability reasons. We very often have to explain to
the client or server framework how to handle the DTO<->JSON/XML
conversions, and annotations are superior to hardcoding for this. Except
when they're not. :-)