On 10.11.2016 15:16, Timothy Ward wrote:
This is where your argument has problems, RSA simply does not equal REST.
RESTful services follow API design principles which are heavily connected to
HTTP, and to the incoming and outgoing wire formats. If I have a REST API used
by my “one page web app” then I simply cannot migrate away from REST to some
other transport. Similarly, REST offers poor remoting characteristics for many
RSA service interface types. HTTP’s request/response flow adds overhead to each
call, caching is not appropriate for most remote service responses… I would
certainly not want to couple the RSA specification to REST.
The upcoming JAX-RS whiteboard standard is all about supporting people who want
to provide a REST API. Where people want to provide remote access to an OSGi
service then I will wholeheartedly recommend that they use RSA in as vendor
neutral way as I can. When people explicitly ask for better ways to provide a
REST API then I will point them to the upcoming standard which offers a
whiteboard model for providing that REST API.
I do not intend to couple RSA to REST. That would indeed make no sense.
What I propose is to use an approach for the JAX-RS whiteboard model
where RSA and the new OSGi JAXRS standard can coexist. I think it makes
sense to offer a REST service in a way so it is OSGi JAX-RS spec
compliant as well as RSA spec compliant.
The JAX-RS spec can take care of how to export the service while RSA can
make sure it also gets reflected in RSA discovery. I do not yet
understand why this is a bad idea? I am pretty sure that those two
aspects can coexist nicely. I will have to look into the JAXRS
whiteboard implementation in detail to get a clearer picture.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
