Musachy Barroso wrote:
What are the plans for the future of the REST plugin? Has anybody
tried to make it more JSR-311 like? I am not a REST user myself, but I
am kind of bored and could help if there was a clear understanding of
what needs to be done.
I haven't touched the REST plugin for a while but actively use it. I'm
pretty happy with it but it needs to be exercised more across broader
areas to find remaining problems.
I use it for public JSON, public HTML and private machine<->machine
services (XML).
I support moving in the direction of JSR-311.
My two biggest issues with the plugin at the moment are:
- a public resoruce that's served as XML would typically reference a
schema and/or namespace. This is possible with XStream by writing to
the outputstream prior to serialization, but it will often be different
for each model. The existing ContentTypeHandler can't readily deal with
this binding between model class and schema and it's up to the plugin
user to invent their own strategy. Not sure if JSR-311 addresses this.,
but it could drive an entirely different approach to consuming a
resource with different content-types.
- exception handling is completely ad hoc (up to the plugin user). I
try to get exceptions to fall through to the ExceptionMapper which then
invokes another action that generates a response consistent with the
requested content type. eg. if they requested XML, they should never get
an HTML stacktrace. Not sure if JSR-311 addresses this. The fragility
in this area means I'd opt for a dedicated WS/RS library rather than use
the plugin for genuinely public resources/services.
- and a third: hierarchical URIs (/book/1/chapter/2) require a custom
actionmapper, but shouldn't. In general, support for params in the path
is a little clunky (and undocumented).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
