I'm not sure I'm convinced. When using the constructor that takes (String jsonString) the passed arg is put into a StringRepresentation which is then stored in this.jsonRepresentation of the JsonRepresentation object. The private getJsonText method then will not use the first if case (because this.jsonObject is still null) and it will fall into the else if case (as this.jsonRepresentation is not null). This case is very simple as it directly takes StringRepresentation.getText() and returns that as the result (in the case where the String based constructor was used, in the case where the Representation based constructor was used the behavior may be a bit more ambiguous).
> If the wrapped representation is not aimed to be parsed (in order to get > a JsonObject, JsonArray, etc) and is only aimed to be written, the > JsonRepresentation is useless. The JsonRepresentation is not useless in this case. All the helpers can still be used to get formal json objects out of the representation using the toJson____() methods (which will parse the underlying string rep but will still never set the internal jsonObject var). Also, the data still represents json formatted data conceptually. I still prefer the string constructor on the JsonRepresentation because it gives much greater control over the json formatting. One can also rely on Restlet's built in handling of media type and any other functionality that might be added or triggered by the variant system. When constructed through String or Representation the JsonRepresentation never changes its nature (it always knows it was not constructed with a json object and never forgets this fact no matter what methods you call on it). In these cases it is very possible to know the size (and even guaranteed to know the size in the String case). This makes the use of the "chunked" header quite unnecessary in these cases, and it breaks and slows down some proxy configurations which then have to do extra work to reassemble the response before passing it on. I have fallen back to using StringRepresentation to overcome this. In addition to needing to add extra json code (where I used to be able to pull the json right out of the representation) it also means I have to jump through more hoops to get a "application-json" header back through manual configuration of something that is supposed to be one of the nice things that Restlet does for you without making you jump through a bunch of hoops. It really does feel like a loophole. If you don't want to allow JsonRepresentation to be used as a convenience wrapper around a String then why provide a constructor that causes it to behave as one? ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428093
