New patch #411-1 is attached. Patch #412-2 is unchanged.
On 2/27/2014 10:40 AM, Ade Lee wrote:
1. Typo in MainCLI.java : Mesage format
Fixed.
2. There appears to be no code to enforce the input to be "json
or xml".
What if someone puts in "XML" or "Json" or "foo" in the CLI
command
line?
The original patch was case insensitive. If someone puts a value that
doesn't translate to a valid MIME media type it will be rejected by the
HTTP client library.
The new patch now only accepts "xml" or "json", case sensitive.
3. So, it looks like we have decided to remove all the
Produces/Consumes
and basically provide all servlets as XML and JSON by default. What
that means though is that we are taking the logic of deciding which
format to return from the framework code.
I'm a little confused as to why this is needed. Doesn't the framework
already do this work for us?
As discussed on IRC, the hardcoded @Provides and @Consumes in the
interface prevent java client from selecting the message format on
demand. There are other options that have been considered (e.g. creating
separate methods for each format, creating separate interfaces for
client & server, moving the annotations to service classes, adding media
type parameter to each method, adding enhancements to RESTEasy), but so
far removing @Provides and @Consumes seems to be one solution that works
with less changes to the server & client code and is available now.
What if the client requests a format like
"application/atom-xml" - and
nothing else. If we follow your code, we will end up returning the
results in whatever format the request came in as. This seems wrong -
we should reject the request with a code 406 (not acceptable). And more
importantly - we should reject this prior to processing which is
presumably what the framework would do - rather than post-processing
when generating the response which is what your code does.
The new patch utilizes a new interceptor to validate the acceptable
message format before the operation is executed. It will throw error 415
on invalid request format and 406 on invalid response format, which is
the same behavior in the existing code.
--
Endi S. Dewata