[xwiki-devs] [VOTE] Port the REST subsystem to JAX-RS
Dear all, this is more a RFC than a vote... Currently the REST subsystem is written using Restlet and its API and there is a layer based on the XWiki Component manager written by me that is used to declare and configure resources and components for providing representations in a more dynamic way. During the last weekend I spent some time experimenting with the JAX- RS API and as a test I tried to port the current implementation to this API. I was able to do so without too much effort and the result was also a drastic reduction in code complexity. In fact all the plumbing I wrote is already handled by the JAX-RS API implementation. Actually the JAX-RS API provides also more powerful mechanisms wrt the ones I wrote because it takes into account representations in responses (GET), representations in requests (PUT and POST) and exception mappings (i.e., the possibility of capturing and representing all kind of exceptions, checked or unchecked). One consequence of these features is that I was able to write methods to handle requests that use our data model without having to deal with complicated try/catch blocks for adjusting the response wrt to exception thrown. Conversions from objects of our data model to representations and viceversa (text/plain, text/xml, etc.) are handled by the framework, and exceptions as well. The problem was the implementation to use. I tried both Jersey and Restlet and both of them were fine. Jersey misses some features such as authentication handling (I had to wrote a basic authentication handler by hand) and is not flexible as Restlet. Restlet, on the contrary, is very powerful and has a very good support for JAX-RS but it lacks automatic generation of the WADL description of the application. Coming to a conclusion, I would like to switch to JAX-RS + Restlet because we can have the best of the two worlds. If we need, in fact, we can still leverage the Restlet API if the JAX-RS is not suitable for implementing a resource. We will have to give up the WADL support for the moment, but I don't think this is a big deal with respect to the gain we have in code maintainability (no more plumbing and easier resource declaration) and reduced code complexity overall. And WADL for JAX-RS will be eventually implemented so it's just a question of time. Here it is my +1 WDYT? Regards, Fabio
Fabio, from your description JAX-RS + Restlet seems to be indeed the best option. Reduced code complexity and increased maintainability are strong arguments to me. So +1. Thanks, Marius Fabio Mancinelli wrote:
Dear all,
this is more a RFC than a vote...
Currently the REST subsystem is written using Restlet and its API and there is a layer based on the XWiki Component manager written by me that is used to declare and configure resources and components for providing representations in a more dynamic way.
During the last weekend I spent some time experimenting with the JAX- RS API and as a test I tried to port the current implementation to this API.
I was able to do so without too much effort and the result was also a drastic reduction in code complexity.
In fact all the plumbing I wrote is already handled by the JAX-RS API implementation. Actually the JAX-RS API provides also more powerful mechanisms wrt the ones I wrote because it takes into account representations in responses (GET), representations in requests (PUT and POST) and exception mappings (i.e., the possibility of capturing and representing all kind of exceptions, checked or unchecked).
One consequence of these features is that I was able to write methods to handle requests that use our data model without having to deal with complicated try/catch blocks for adjusting the response wrt to exception thrown. Conversions from objects of our data model to representations and viceversa (text/plain, text/xml, etc.) are handled by the framework, and exceptions as well.
The problem was the implementation to use. I tried both Jersey and Restlet and both of them were fine.
Jersey misses some features such as authentication handling (I had to wrote a basic authentication handler by hand) and is not flexible as Restlet. Restlet, on the contrary, is very powerful and has a very good support for JAX-RS but it lacks automatic generation of the WADL description of the application.
Coming to a conclusion, I would like to switch to JAX-RS + Restlet because we can have the best of the two worlds. If we need, in fact, we can still leverage the Restlet API if the JAX-RS is not suitable for implementing a resource. We will have to give up the WADL support for the moment, but I don't think this is a big deal with respect to the gain we have in code maintainability (no more plumbing and easier resource declaration) and reduced code complexity overall. And WADL for JAX-RS will be eventually implemented so it's just a question of time.
Here it is my +1
WDYT?
Regards, Fabio
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for me, as long as there are no gotchas that you are unaware of. :) Fabio Mancinelli wrote:
Dear all,
this is more a RFC than a vote...
Currently the REST subsystem is written using Restlet and its API and there is a layer based on the XWiki Component manager written by me that is used to declare and configure resources and components for providing representations in a more dynamic way.
During the last weekend I spent some time experimenting with the JAX- RS API and as a test I tried to port the current implementation to this API.
I was able to do so without too much effort and the result was also a drastic reduction in code complexity.
In fact all the plumbing I wrote is already handled by the JAX-RS API implementation. Actually the JAX-RS API provides also more powerful mechanisms wrt the ones I wrote because it takes into account representations in responses (GET), representations in requests (PUT and POST) and exception mappings (i.e., the possibility of capturing and representing all kind of exceptions, checked or unchecked).
One consequence of these features is that I was able to write methods to handle requests that use our data model without having to deal with complicated try/catch blocks for adjusting the response wrt to exception thrown. Conversions from objects of our data model to representations and viceversa (text/plain, text/xml, etc.) are handled by the framework, and exceptions as well.
The problem was the implementation to use. I tried both Jersey and Restlet and both of them were fine.
Jersey misses some features such as authentication handling (I had to wrote a basic authentication handler by hand) and is not flexible as Restlet. Restlet, on the contrary, is very powerful and has a very good support for JAX-RS but it lacks automatic generation of the WADL description of the application.
Coming to a conclusion, I would like to switch to JAX-RS + Restlet because we can have the best of the two worlds. If we need, in fact, we can still leverage the Restlet API if the JAX-RS is not suitable for implementing a resource. We will have to give up the WADL support for the moment, but I don't think this is a big deal with respect to the gain we have in code maintainability (no more plumbing and easier resource declaration) and reduced code complexity overall. And WADL for JAX-RS will be eventually implemented so it's just a question of time.
Here it is my +1
WDYT?
Regards, Fabio
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 13, 2009, at 9:41 AM, Eduard Moraru wrote:
+1 for me, as long as there are no gotchas that you are unaware of. :)
Well, I have an equivalent implementation right now (modulo WADL) Though I've just found a weird behavior that I am investigating [1] :( I'll keep you informed. Fabio [1] http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=11502...
+1 Thanks -Vincent On Feb 12, 2009, at 11:18 PM, Fabio Mancinelli wrote:
Dear all,
this is more a RFC than a vote...
Currently the REST subsystem is written using Restlet and its API and there is a layer based on the XWiki Component manager written by me that is used to declare and configure resources and components for providing representations in a more dynamic way.
During the last weekend I spent some time experimenting with the JAX- RS API and as a test I tried to port the current implementation to this API.
I was able to do so without too much effort and the result was also a drastic reduction in code complexity.
In fact all the plumbing I wrote is already handled by the JAX-RS API implementation. Actually the JAX-RS API provides also more powerful mechanisms wrt the ones I wrote because it takes into account representations in responses (GET), representations in requests (PUT and POST) and exception mappings (i.e., the possibility of capturing and representing all kind of exceptions, checked or unchecked).
One consequence of these features is that I was able to write methods to handle requests that use our data model without having to deal with complicated try/catch blocks for adjusting the response wrt to exception thrown. Conversions from objects of our data model to representations and viceversa (text/plain, text/xml, etc.) are handled by the framework, and exceptions as well.
The problem was the implementation to use. I tried both Jersey and Restlet and both of them were fine.
Jersey misses some features such as authentication handling (I had to wrote a basic authentication handler by hand) and is not flexible as Restlet. Restlet, on the contrary, is very powerful and has a very good support for JAX-RS but it lacks automatic generation of the WADL description of the application.
Coming to a conclusion, I would like to switch to JAX-RS + Restlet because we can have the best of the two worlds. If we need, in fact, we can still leverage the Restlet API if the JAX-RS is not suitable for implementing a resource. We will have to give up the WADL support for the moment, but I don't think this is a big deal with respect to the gain we have in code maintainability (no more plumbing and easier resource declaration) and reduced code complexity overall. And WADL for JAX-RS will be eventually implemented so it's just a question of time.
Here it is my +1
WDYT?
Regards,
participants (4)
-
Eduard Moraru -
Fabio Mancinelli -
Marius Dumitru Florea -
Vincent Massol