Hi Carl-Erik See comments inline please, I
<snip/> > > There is absolutely no need for us to use form encoded submissions; we > have just chosen it for the reasons you suggest (convenience mostly): > 1. It allows for arbitrarily long submissions by using POST (although > using GET would probably be more sementically correct. Internet > Explorer 2K GET limit is a show-stopper.) > 2. We can use multiple arguments, making it easy to "translate" > existing SOAP based web services. > 3. It allows for default values, missing values, and (importantly!) > the possibility of changing the API (by adding more parameters to a > method) without breaking existing clients. > 4. WADL > > We were especially concerned with (3) when considering using a single > composite object to represent all the parameters for a service, as we > were unsure of what would happen to the deserialization of an object > when fields were missing. This could happen if data were sent from a > client that was developed earlier. > That is an important issue. We are actually taking it seriously in CXF, for example see http://cxf.apache.org/docs/transformationfeature.html That feature simplify dealing with the compatibility issues, but generally speaking, one can handle pretty much any such issue in CXF by registering custom STAX handlers or preprocessing non-XML payloads as needed. FYI, Transform feature works for JSON payloads too, provided a Jettison-based provider is used. > I knew this would work out fine with @FormParam, but quite unsure > about how well the "composite route" would fare in this case. Your > reply nonetheless caused me to play around with the "composite" > approach, and now I see that it is not a problem, as missing fields in > the JSON representation will simply be null when deserialized. That > was a relief, as that means (3) is not an issue. This also opens up > for consuming other content types, such as xml, which is a nice bonus. > Yes indeed > Unfortunately, the composite approach makes the WADL quite useless, as > there is no information in it saying what to pass to the service. Any > client developer would have to have either access to the server source > code or a hand written description from the server side developers > describing the legal parameters. Not very attractive ... But maybe you > could enlighten me; is there any way to squeeze out more info than the > following if using the "composite parameter object approach"? > .. > <resource path="/oneParam"> > <method name="POST"> > <request> > <representation mediaType="application/json"/> > </request> > <response> > <representation mediaType="application/json"/> > </response> > </method> > </resource> > ... > FYI, it is possible to configure WADlGenerator to include external schemas and explicitly link certain representations with schema elements. I'm wondering, what would happen if a JSON schema is included...I'll need to play with that. >> Also, do you need to use JSON or do you use it because Jackson offers >> a useful Mapper class which can convert a JSON sequence into a complex >> bean. > We need to pass various complex object hierarchies as arguments, and > thus we needed serialization format. JSON was chosen over XML as the > serialization format, due mainly to mobile html5 clients with low > bandwidth. I was not very pleased with the hackish approach I > described, where I was mixing json-encoded objects and vanilla > string-representations, but it worked - albeit at the expense of > loosing tools based on the common standards. > >> Just would like to understand your requirements better. CXF offers an >> extension such as FormParam(""), so you can have >> (@FormParam("myPrimitive") int myPrimitive, @FormParam("") MyObject >> myComplex) >> but that will work only for plain name/value pairs, but won't when >> values are actually JSON sequences. > Hmm ... You basically mean that if I passed in a string > "myPrimitive=100&foo=abc&bar=def&baz=ghf" in the content body, it > would work? Too bad I need nested objects ... :-( That extension supports nested objects. Lists and soon Maps will also be supported. Cheers, Sergey > -- Sergey Beryozkin Application Integration Division of Talend http://sberyozkin.blogspot.com
