Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe03.iad.POSTED!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... References: <51340ae1$0$32109$14726298@news.sunsite.dk> In-Reply-To: <51340ae1$0$32109$14726298@news.sunsite.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Lines: 99 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Mon, 04 Mar 2013 09:53:22 UTC Organization: Public Usenet Newsgroup Access Date: Mon, 04 Mar 2013 05:53:21 -0400 X-Received-Bytes: 5104 Xref: csiph.com comp.lang.java.programmer:22710 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. > > Arne 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. :-) AHS [1] My uses of REST are almost always trivial. There is no hypertext-driven application state because the interactions are stateless in the REST sense. They may not be stateless in the system (DELETE, PUT, POST) but I never expect the client to follow-up on a REST call.